ENGINE 42
SFS-E42-USM · SALES ADMINISTRATION · REV 2026-07-24 · PRODUCTION
PRODUCTION = runnable end-to-end, CI-backed, full test suite passing. All data fictional and seeded.
Unit Sales & Commission Tie-Out
Does the Matrix still tie to the tabs that feed it?
A residential for-sale project is administered out of one workbook, instantiated from the same template on every project, and that workbook has to prove itself row by row. The Matrix tab carries every unit -- plan, plan square footage, list price, sales price, concession, revenue per square foot, closing costs and total selling commission. The Sold/Close tab logs the offer date, the actual date sold, the closing date and whether proof of closing came back. The Commission Log splits each unit's total commission across the named selling agents who earned it. This engine reads the seven artifacts that record emits -- the plan register, the Matrix, the commission schedule, the Sold/Close log, the agent register, the Commission Log and the sales rollup -- and runs twenty-one deterministic controls over them. Is the file complete and the review date readable, are the plan codes unique and every plan area a positive whole count, is every Matrix row complete, uniquely identified, on a declared plan and in a known status, does revenue per square foot re-derive as the sales price over the plan area, does net proceeds re-derive as price less concession less closing costs, does the concession sit inside the price it discounts, was the discount to list inside the sales office's own band, is the unit's sale channel priced on the commission schedule, does the total commission re-derive as the channel rate on the sales price, do the Commission-Log splits sum to exactly the total the Matrix authorised, is every payee in the agent register, do the sold units reconcile one-to-one to the Sold/Close tab in offer-sale-closing order with proof on file, and do the rollup's sold count, revenue totals and commission total recompute from the Matrix beneath them. Every derived figure is compared with exact == in integer cents, truncation is the contract in both directions so a floored derivation can be compared to a stated figure without a tolerance band, every closing test is measured to the review date the file carries rather than the system clock, and no source artifact is ever written.
The Matrix foots, which is exactly why nobody re-adds it. A derived column is a formula until somebody types over one cell of it for one unit, and from that moment the column is a mixture of computed and typed figures that no longer follows from the prices beside it -- and the mixture is invisible on a printed tab. The Commission Log keeps paying a total the Matrix no longer authorises: a split edited after the fact, or an agent added without reducing another, pays an amount no row approved, and because one template is instantiated on every project the same cent recurs on every unit it produced. And the tabs quietly stop reconciling -- a unit marked sold that never reaches the Sold/Close tab, a closing logged with the sale date before the offer that produced it, a rollup that leaves the sales office carrying a count the Matrix does not support. None of those look wrong on the tab. The engine rebuilds every derived figure -- revenue per square foot, net proceeds, total commission, each agent's split in cents and all three rollup totals -- from the base prices through the same tie-out kernel that produced the data, compares with exact == in integer cents, reconciles the Sold/Close tab in both directions, ships a planted-defect file for every registered control, and states its benchmark as a command rather than a claim.
Architecture
functional block stack · static overviewSelect a layer
Seven control families run in registry order over each sales file. The first proves the others had something to read and that the review date is legible, because a control that passes on absent evidence reports assurance it never performed.
Key specifications
at a glanceWhat it does for you
plain termsA residential for-sale project -- condo or townhome -- is administered out of one workbook, instantiated from the same template on every project, and the same three failures recur in each instantiation. The Matrix tab carries every unit: plan, plan square footage, list price, sales price, concession, revenue per square foot, closing costs and total selling commission. The Sold/Close tab logs the offer date, the actual date sold, the closing date and whether proof of closing came back. The Commission Log splits each unit's total commission across the named selling agents who earned it. First, a derived column stops deriving: revenue per square foot, net proceeds and total commission are formulas until somebody types over one of them for a single unit, and from then on the column is a mixture of computed and typed figures that no longer follows from the prices beside it -- and the mixture is invisible on a printed tab. Second, the commission splits stop adding up: the log pays named agents, the sum of the splits on a unit is meant to be the total the Matrix authorised, and a split edited after the fact or an agent added without reducing another leaves the log paying an amount no row ever approved. Third, the tabs stop reconciling: a unit is marked sold and never reaches the Sold/Close tab, a closing is logged with the sale date before the offer date, or the rollup that leaves the sales office states a count and a revenue total the Matrix does not support. None of these are judgment calls. They are equalities and comparisons -- a stated figure against its re-derivation with exact == in integer cents, a set of splits against the total it divides, a set of sold ids against a set of closing ids in both directions, three dates against each other with <= -- which a deterministic control settles better than a workbook inherited by whoever administers sales this quarter.
The seeded demo runs every control over every sales file7. The CLI generates twenty-three fictional sales files -- one clean baseline and one carrying each of the twenty-two planted defects -- then runs all twenty-one controls over each. The clean file returns PASS with no flags; every defect file returns REVIEW or FAIL and names the control it tripped along with the reason that control exists.
The splits are compared against the row that authorised them8. A defect file shortens one agent's split on UNIT-105 by a hundred dollars and leaves every other figure untouched, so the Commission Log still looks internally orderly and the Matrix still foots. comm_splits_tie sums the three logged splits on the unit, compares them in integer cents with exact == to the total commission the Matrix row authorised, and reports the shortfall against the row that approved it.
The Sold/Close reconciliation runs both ways9. One defect file deletes the closing row for UNIT-104 while the Matrix still marks it sold, and close_sold_reconciles reports revenue the Matrix claims that the tab cannot evidence. The same control tests the other direction on every file -- a closing row for a unit the Matrix does not call sold -- which is the harder break to notice and the one that leaves a settled sale out of the period.
Functional block diagram
engineering · each block links to its sourcePlain terms
- Seeded Sales Files. fictional for-sale sales files enter the control registry
- Structural Precondition. is the sales file complete and the review date legible
- Plan Register. is every plan code unique and every plan area real
- Matrix Rows. is every Matrix row well-formed, unique and typed
- Price Re-Derivation. does the price arithmetic on the row re-derive
- Commission and Split. does the commission re-derive and does the log split it exactly
- Sold/Close Reconciliation. do the sold units and the closings reconcile both ways
- Rollup Tie-Out. does the rollup recompute from the Matrix it summarises
- Matrix, Schedule & Registers. the artifacts and rates every rule resolves against
- Verdict and Findings. every finding, with the reason it exists, ends at a person
Engineering
- Seeded Sales Files. generate_corpus writes one clean baseline plus one planted-defect file for every registered control, twenty-three files in total. Only the plans, the commission schedule, the unit base prices, the Sold/Close dates and the agent split weights are stated; revenue per square foot, net proceeds, total commission, each agent's split in cents and the three rollup totals are re-derived through the same tie-out kernel the engine later recomputes with, so the relationships the engine tests are the relationships that produced the data. A defect that moves a base fact re-derives the Matrix and keeps the break confined to one control; a defect that targets a derived figure edits that cell alone.
- Structural Precondition. One control. FAILs a file missing any of the seven artifact types or carrying a duplicate of one, and FAILs an unreadable as_of, so no downstream rule holds vacuously on absent evidence.
- Plan Register. Two controls: no plan code appears twice, and every plan carries a positive whole square footage -- the denominator revenue per square foot divides by.
- Matrix Rows. Four controls: the required descriptive fields are present, unit ids are unique, every row names a declared plan, and every status is one of available, reserved or sold.
- Price Re-Derivation. Four controls: revenue per square foot is the sales price over the plan area floored, net proceeds is price less concession less closing costs, the concession sits inside the price it discounts, and a sold unit discounted past the file's own band is flagged for a signature.
- Commission and Split. Four controls: the sale channel is priced on the schedule, the total commission is the channel rate on the sales price with truncating basis-point arithmetic, the Commission-Log splits sum to that total with exact ==, and every payee is in the agent register.
- Sold/Close Reconciliation. Three controls: every unit marked sold has a closing row and every closing row names a unit the Matrix marks sold, the offer, sale and closing dates run forward, and a closing whose date has arrived carries its proof of closing.
- Rollup Tie-Out. Three controls: the sold-unit count is recounted from the Matrix, the sales price and net proceeds totals are summed over the sold rows, and the commission total is summed over the whole commission column.
- Matrix, Schedule & Registers. The plan register carries each plan's code, name and square footage; the Matrix carries each unit's plan, sale channel, status, list price, sales price, concession, closing costs and the three derived columns; the commission schedule carries the basis-point rate per sale channel; the Sold/Close log carries the offer, sale and closing dates and the received-proof flag; the agent register names every payee a split can reach; the Commission Log carries each split's basis-point weight and its cents; and the file itself carries the review date and the approved discount band. Every price, commission, closing and rollup control resolves against these through the shared tie-out kernel.
- Verdict and Findings. Findings roll up per sales file: any FAIL is FAIL, FLAGs without FAILs are REVIEW, clean is PASS. The CLI exit code is the verdict, so a pipeline can gate on it. Reports carry no timestamps or absolute paths, which is what makes the committed report diffable -- a change in the diff is a change in the controls, not a change in when the report was run.
Instruction set
every public command| Command | Operation | Output | Exit | Artifacts |
|---|---|---|---|---|
python run.py | regenerate the seeded fictional corpus, run all twenty-one controls, write both reports | per-file verdicts and every actionable finding, then the overall verdict | 2 for the bundled corpus, which carries a planted defect for every control by design | sales_report.json, sales_report.md, samples/ |
python -m sales_engine samples | analyze an existing folder of sales files without regenerating it | per-file verdicts and findings | 0 PASS / 1 REVIEW / 2 FAIL / 3 usage | none unless --json or --md is passed |
python -m sales_engine samples --generate --quiet | regenerate the corpus and print only the overall verdict | a single verdict line | 0 PASS / 1 REVIEW / 2 FAIL / 3 usage | samples/ |
python -m pytest sales_engine/tests -q | run the full test suite for this engine | 10355 passed | 0 when every test passes | none |
Benchmarks
measured demo results| Measure | Result |
|---|---|
| Engine tests10 | 10,355 tests collected live collection from the engine directory |
| Registered controls11 | 21 controls counted from the registry, not from documentation |
| Planted defects12 | 22 defect files every registered control has at least one file that trips it |
| Control coverage13 | 100 percent of controls with a planted defect no control ships without a file demonstrating it firing |
Control characteristics
engineeringPlain terms
The engine has no write path and therefore no autonomy to gate. It produces findings; a person decides whether a commission is released, a closing is chased and a rollup is sent.
Engineering
Deterministic envelope. seeded fictional inputs, read-only operation, offline default mode.
Demo gate. FAIL on the bundled corpus, by design -- it carries a planted defect for every registered control
| Severity | Verdict | Action |
|---|---|---|
| No findings above PASS | PASS | carry the mechanically clean sales file into the documented sales-administration review and sign-off |
| One or more FLAG, no FAIL | REVIEW | a human resolves each flag; a sold unit discounted past the approved band and a due closing whose proof has not come back both land here |
| One or more FAIL | FAIL | the figure is not carried into the rollup or the commission run until the failing control is cleared -- a derived column that does not recompute, a split that does not tie, an unreconciled closing, a date sequence that runs backwards, or a rollup total that does not foot |
- Read-only: sales files are parsed and never written back, so the engine cannot introduce the break it reports.
- Integer cents throughout, compared with exact ==; there is no tolerance band on a derived figure, and a cent off the re-derivation is reported as a break.
- One tie-out kernel: the controls and the generator share the arithmetic in sales_engine.tieout, so a derived column cannot disagree with the data that produced it.
- Truncation is the contract in both directions -- revenue per square foot floors and the commission rate is applied with truncating basis-point arithmetic -- so a derived figure can be compared to the stated figure with exact ==.
- A figure that should be integer cents but is not produces an AMOUNT_INVALID finding contained to the one row it was read on, rather than being coerced into the number the engine is meant to audit.
- Every closing and proof test is measured to the review date the file carries, never to the system clock, so a run in a later month returns the same findings.
- Commission splits are allocated by the largest-remainder method, so the residual cent lands on one named agent rather than disappearing into the rounding.
- Deterministic and byte-stable: same inputs produce the same findings in the same order, with no timestamps or absolute paths in any output.
- Absent evidence is never a passing control; a missing artifact fails completeness rather than letting the controls that read it pass unread.
Operating limits
what it refuses to do- The engine never posts a journal entry, releases a commission payment, files a closing statement or writes to a source artifact. It reads the sales file and stops.14
- It reads the seven artifacts the sales-administration record emits. It does not connect to a general ledger, an escrow or title system, a payroll or commission-payment run, or the underlying purchase contracts.15
- It proves the Matrix is internally true, not that a price was the right price or that a discount past the approved band should have been granted. Whether a struck price is commercially sound is a judgment the flag routes to a person.16
- It re-derives every commission at the basis-point rate the file's own commission schedule carries for the unit's sale channel; it does not decide whether that rate, that channel or that split weight is the one the agent's agreement provides for.17
- It takes the Sold/Close records at face value: it confirms the tabs reconcile and the dates run forward, not that a sale or a settlement actually occurred. All shipped data is fictional -- the developers, projects, plans, unit numbers, selling agents, prices and closing dates are invented, and the sales period is set in a fictional future.18
See it run
control architecture
Integration
how to run itDistribution: public repository, MIT license.
- 1python -m pytest --collect-only -q -o addopts= (unit-sales-automation/)
- 2len(sales_engine.engine.REGISTRY)
- 3distinct rule-id prefixes in sales_engine.engine.REGISTRY
- 4samples/*.json after python run.py
- 5len(sales_engine.model.DOC_TYPES)
- 6sales_engine/tests boundary tests on the cent, the basis point and the day
- 7python run.py (unit-sales-automation/); sales_engine/tests planted-defect suite
- 8sales_engine/generate.py DEFECTS agent_split_short -> comm_splits_tie
- 9sales_engine/generate.py DEFECTS close_row_missing -> close_sold_reconciles
- 10python -m pytest --collect-only -q -o addopts= (unit-sales-automation/)
- 11len(sales_engine.engine.REGISTRY)
- 12len(sales_engine.generate.DEFECTS)
- 13sales_engine/tests: every registered rule has a planted defect
- 14unit-sales-automation/README.md and sales_engine read-only / determinism tests
- 15sales_engine/model.py DOC_TYPES
- 16sales_engine/engine.py price_discount_to_list
- 17sales_engine/engine.py comm_rate_defined and comm_total_recomputes
- 18sales_engine/generate.py
Show us where the hours go.
One conversation: you describe the work that consumes your team's month; we tell you plainly what this engine can take over, what it can't, and what a scoped first phase would cost. Your people keep approval authority.
Book a free consultation