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.
The analyst who knows the field writes the row. A developer reviews. That is the reverse of today.
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.
The workbook
The source tree, the target tree and one expression per field, in a file an analyst can read and the engine can run. Format and validation sit beside the value they govern, so presentation and rules never move into code.
| S1 | S2 | S3 | Source type |
|---|---|---|---|
| trade | |||
| tradeId | String | ||
| buySell | String | ||
| quantity | Double | ||
| tradePrice | Double | ||
| instrument | |||
| exchange | String | ||
| lastTradeableDate | String |
The source columns hold the tree your table already has, nested as it is, with the type of each leaf. Nothing is flattened on the way in. Every expression on the target side is checked against this declaration before a row is read.
The first version of this section is produced from your schema. Analysts never transcribe a data model.
| T1 | T2 | T3 | T4 | Mandatory | Target expression | Format | Validation |
|---|---|---|---|---|---|---|---|
| Execution | |||||||
| TradeID | true | trade.tradeId | |||||
| ExtractDate | true | LocalDate.now() | yyyy-MM-dd | ||||
| Economics | |||||||
| Price | true | trade.tradePrice | #.#### | ||||
| Amount | true | quantity * (buySell == 'Sell' ? -1 : 1) | Amount == 0 ? 'zero quantity' : '' | ||||
| Identifier | |||||||
| Exchange | true | getExchange(instrument.exchange) ?: instrument.exchange | Exchange == 'NYM' ? 'should be mapped to XNYM' : '' |
The feed's tree, written by indentation. Nesting in the sheet is nesting in the output, and nobody codes the structure.
true or false per field. A missing value is reported on that field, in words. Nothing is thrown.
How the value is computed. A plain path for the common case, a real expression when the field needs one.
A pattern for numbers and dates. Presentation stays separate from computation.
A rule that may read other fields. It runs as the record is produced and says why the field failed.
Indentation is nesting
Each target row becomes one field. A row with no expression is a node, and the rows indented beneath it are its children. The feed on the right was written from the sheet on the left with no code in between.
Flat output works the same way: for CSV, each leaf row becomes a column.
valid.json · one record, abridged"Execution": {
"TradeID": "T-20931",
"ExtractDate": "2026-09-16",
"Economics": {
"Price": "81.82",
"Amount": -1000.0,
"Identifier": {
"Exchange": "XNYM"
}
}
}
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.
The table, the row filter and the workbook, one entry per product. Adding a table is one more entry and a generated workbook.
schema:
tables:
commodityFuture:
table: "listed_derivative_trade"
filter: "product.productType = 'COMMODITY_FUTURE'"
mapping: "commodityFuture.xlsx"
# one entry per product or source system
Each command reads the file the previous one wrote. The analyst's work sits between the second and the third.
$ run.sh schema read the schema file, write a type schema per table $ run.sh mapping generate the first workbook from the schema (analysts then fill in the Target expression column) $ run.sh validate check every expression against the declared types $ run.sh transform map the rows, write the feed and its evidence
The workbook does not know which shape it feeds. The same leaf row writes a node in JSON and a column in CSV.
| T2 | T3 | Target expression | Format |
|---|---|---|---|
| Economics | Price | trade.tradePrice | #.#### |
"Economics": {
"Price": "81.82"
}
TradeID,Economics.Price T-20931,81.82
Everything the validator can know from the declared types is refused before any data. Whatever it could not know statically is caught per field at evaluation, with the same wording.
Unknown variable: tradeId2
No such property 'venue' on instrument
No such method 'round' with 0 argument(s) on Double
Unsupported method: collect
Unsupported static method: Integer.parseInt
Division by literal zero
Cannot get property 'contractSize' on null
Cannot compare Integer with String
Unknown constant: MAX_SIZE
Error invoking getExchange: ...
The pilot
Engineering names the table, the row filter and the workbook in the schema file.
The first version is produced from your schema, source tree and types included.
One expression per target field, with format and validation beside it. Lookups become sheets.
The engine runs on your batch schedule for one cycle, writing its own output next to the current one.
Two feeds, lined up. Every difference names its field and carries its explanation.
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.