How it works
A partner sends a spreadsheet. Here is everything that happens to it.
Written for whoever you forward this to. It says where the model is, where it is deliberately not, and what happens when a file cannot be read — which is the part that decides whether this is a product or a services contract in disguise.
Extraction is a cascade, cheapest path first
Five stages, each one used only when the one before it failed. Most partner files repeat month after month, and the expensive path should be reserved for the files that are genuinely new.
Fingerprint
A structural hash of the file — sheet names, header row, column signature. An exact match to a known layout runs a deterministic parser that was written once. By month six this should be most of the volume, and it costs approximately nothing.
Near match
A fuzzy match inside the same family. If the difference is small the existing mapping is applied and the change is flagged for a person to confirm, rather than silently accepted.
Model-assisted mapping
A model proposes how the columns map to your schema, over a sample rather than the whole file. A person confirms the mapping once, and from then on the mapping is deterministic code. The model writes the parser; it is not the parser.
Document extraction
For PDFs and scans: layout analysis, then vision extraction with a confidence score per field. Fields below threshold are not guessed.
A person
Anything the four stages above could not resolve lands in a queue with the rows in question and the reason. Those rows stay out of every total until they are resolved.
The asset being built here is not a model. It is a library of partner file layouts and the parsers that read them, and it gets cheaper with every customer in the same industry.
When a partner changes their layout
They will. Someone adds a column, renames a header, or exports from a new system, and the integration that worked for eleven months stops working in the twelfth. This is the moment that decides whether channel data is a product or a services contract.
Windrose opens the file against the last accepted version of that layout and shows the difference. Only the fields that changed need confirming. Forty-one fields carry over; three get a look. A twenty-minute re-mapping becomes a ninety-second review, and the accepted version becomes the new baseline.
Nothing is committed while a required field is unmapped, and the count of unmapped fields sits above the fold rather than at the end of a scroll.
The model is never in the decision path
Entitlement is decided by a rule engine, not by a language model. Rules are typed, versioned data evaluated as sandboxed expressions, and every evaluation emits a trace: which rule, which version, which inputs, which branch was taken.
A model may read your contract and propose a rule. That proposal is inert. It becomes a rule when a named person confirms it, and the field recording who confirmed it cannot be empty. The same applies to a mapping, a match between two sub-dealer records, and a dispute — a model can propose, and a person decides.
Every model call goes through one gateway, which pins the region, versions the prompt, validates the response against a schema, and attributes the cost. No provider library is imported anywhere else in the codebase, and a check fails the build if one is.
| Decision | Who makes it |
|---|---|
| How a column maps to your schema | Proposed by a model, confirmed once by a person, deterministic after that |
| Whether a claim breaches entitlement | Rule engine, versioned, traced |
| Whether a dispute is issued | A named person, and a second person approves |
| Whether two sub-dealer records are the same company | Proposed with a score, confirmed by a person above the ambiguous band |
| Whether to place a replenishment order | You. Windrose drafts it and never sends it |
Where this is today
Windrose is being built, and this is the honest state of it. The four agents are specified end to end. The data model, the rule engine and the evidence trail are built. Four product screens read live data; the rest render design fixtures while the services behind them are finished.
That is why this site offers a retrospective on your own claims rather than a demo. A demo of a screen rendering fixtures is a picture, and the first question you would ask is one a picture cannot answer. A retrospective answers it with your numbers.
For the detailed version of this page as a deck you can forward: hello@windrosechannel.com. Or read what a retrospective involves.