Generate data-transformation functions from specifications

Why use this

1. An engineering team generating transformation functions may have clear-looking specifications that omit null behavior, units or error handling. A function can match the happy-path example while silently corrupting edge cases downstream.

2. A mapping-and-test proposal could expose those decisions before code is reviewed or deployed. Engineers could distinguish specified behavior from questions needing the data owner and retain responsibility for access, tests and production operation.

Why an agent / simpler alternative

Useful judgment

Translate field-level specifications into candidate logic and identify underspecified edge cases.

Simpler alternative

Use a declarative mapping or existing ETL tool when transformations are simple and stable.

Unsuitable when

Data semantics, security boundaries or deployment authority is unresolved.

Proposed inputs

1. Name

   Transformation specification

   Owner

   Data owner

   Minimum scope

   Input/output schemas, units and explicit mapping/error rules

   Quality check

   Confirm version and ownership of ambiguous field meanings.

2. Name

   Synthetic examples and runtime constraints

   Owner

   Engineering owner

   Minimum scope

   Representative non-sensitive inputs and target interface expectations

   Quality check

   Include null, malformed and boundary cases without production credentials.

Access and setup — proposed or unknown

Proposed minimum

1. Offline specifications and proposed code/test design; no cloud access.

Compatibility unknowns

1. Unknown: exact runtime, AWS Lambda configuration, dependency support and internal tool access.

External actions requiring approval

1. Writing shared repositories, configuring credentials, accessing real data or deploying functions.

Expected deliverable and review checks

Proposed artifact

Candidate transformation design with source-field mapping and proposed acceptance cases.

Critical checks

1. Every output field has an approved input basis.

2. Nulls, units and failure handling remain explicit rather than inferred silently.

Missing output evidence

No new workflow run or output inspection was performed for this overlay.

Failure signals and proposed responses

1. Signal

   Missing numeric values are converted to zero by default.

   Why it matters

   The output could change business meaning without an approved rule.

   Proposed response

   Hold that mapping and request the intended missing-value treatment.

2. Signal

   Two source fields use different units under similar names.

   Why it matters

   A plausible transformation may produce wrong magnitudes.

   Proposed response

   Require explicit unit conversion rules and review examples.

Effort and cost — unknown

Setup work

1. Resolve schema semantics and define edge-case expectations.

Ongoing review

1. Review candidate code and run authorized mapping/security tests separately.

Unknowns

1. Unknown: cloud costs, runtime limits and specification completeness.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

An invented mapping specification omits null handling and labels one amount in a different unit.

Acceptance checks

1. Both gaps appear as unresolved requirements.

2. No generated-function correctness is claimed.

Stop conditions

1. Production data, credentials or an invented mapping rule is needed.

Limits

1. Editorial engineering plan; a synthetic specification review is not code, integration or runtime validation.