Your analysts already keep a spreadsheet that says what every field in your regulatory and surveillance feeds should contain. Today someone else turns it into code. expressionmap runs the spreadsheet itself: point it at your trade data, and it writes the feed with every field checked and every value explained.
| Target field | Expression | Validation |
|---|---|---|
| Economics.Amount | quantity * (buySell == 'Sell' ? -1 : 1) | Amount == 0 ? 'zero quantity' : '' |
What the consumer receives"Economics": {
"Amount": -1000.0,
"Price": "81.82"
}
Why each field holds that value"Economics": {
"Amount": "quantity=1000.0, buySell=Sell",
"Price": "tradePrice=81.82"
}
The problem
In most trading firms the business owns a mapping spreadsheet and engineering owns a transformation layer that is supposed to match it. The two drift. Every fix waits for a release, and nobody outside engineering can see what actually runs.
How it works
Name the table, the row filter and the workbook in one schema file. The source tree and every field type are read from your data, nested as it already is.
The first version of the mapping is produced from the schema, not typed. The target tree is written by indentation: nesting in the sheet is nesting in the output.
A plain path for the common case, a real expression when needed. Format and validation rules sit beside the value in the same row. Lookups and reference calls are rows too.
Every expression is checked against the declared types before a single row is read. Then the batch runs and writes the feed, with its evidence beside it.
For the business
The workbook your analysts review is the workbook the engine runs. A missing lookup value is fixed by adding a row. A changed rule is an edit and a review. Onboarding a new product is measured in analyst days, not sprints.
Expressions from a real workbook
For operations
When the workbook loads, every expression is checked against the declared source types. A typo is refused with a row number before a single row is read. At run time, one bad field does not sink the record: the rest maps, and the failure names the field and the reason in words an analyst can act on.
One run, three files
For audit and support
Beside every output file, the engine writes a source file in the same shape. For each field it records the path that was read and the value it held at the moment the field was produced. The feed says what was sent. The source file says why, for every field, for every record, on every run. An analyst lines them up side by side.
Today: one question, four hops
With expressionmap: one hop
For engineering
The engine is a library that follows the workbook. It is the same binary for every feed, every table and every output shape, so the code footprint for a new feed is the workbook: in most cases zero lines of custom code.
Java-like expressions over ten source types, with safe navigation, elvis and ternaries. No statements, no assignment, no loops. Only a short list of classes and methods can be named; anything else is refused by the validator. Money math is exact by default.
A workbook, a sample record and an expected output run as a unit test on every build. A bad workbook never reaches production: it fails to load, with the row number, before any data flows.
Four commands: schema, mapping, validate, transform. Source is any table you expose. Reference data arrives over REST. Output is nested JSON or flat CSV from the same workbook, written where your consumer already reads.
Pick one feed. We map it from the table you already expose, run it on your batch schedule for one cycle, and compare the two outputs field by field. You keep the workbook either way.