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.

Run it Book a consultation

Architecture

functional block stack · static overview
Structural Precondition Plan Register Matrix Rows Price Re-Derivation Commission and Split Sold/Close Reconciliation Rollup Tie-Out substrate: seeded fictional data

Select 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 glance
10,3551
Tests
the collected checks that pin this engine's behavior
212
Controls
independent rules run over every sales file
73
Families
groups of controls, each answering one question
234
Sales files
one clean baseline plus twenty-two planted-defect files
75
Artifacts read
plan register, Matrix, commission schedule, Sold/Close log, agent register, Commission Log, sales rollup
06
Tolerance
a derived figure a cent off its re-derivation is a break, not a rounding band

What it does for you

plain terms

A 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 source
Functional block diagram of the Unit Sales & Commission Tie-Out engine sales files sales files sales files sales files sales files sales files sales files resolves resolves resolves resolves resolves resolves resolves sales price findings findings findings findings Seeded Sales Files StructuralPrecondition Plan Register Matrix Rows Price Re-Derivation Commission and Split Sold/CloseReconciliation Rollup Tie-Out Matrix, Schedule& Registers Verdict and Findings SFS-E42-USM · FUNCTIONAL BLOCK DIAGRAM · REV 2026-07-24

Plain 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
CommandOperationOutputExitArtifacts
python run.py
regenerate the seeded fictional corpus, run all twenty-one controls, write both reportsper-file verdicts and every actionable finding, then the overall verdict2 for the bundled corpus, which carries a planted defect for every control by designsales_report.json, sales_report.md, samples/
python -m sales_engine samples
analyze an existing folder of sales files without regenerating itper-file verdicts and findings0 PASS / 1 REVIEW / 2 FAIL / 3 usagenone unless --json or --md is passed
python -m sales_engine samples --generate --quiet
regenerate the corpus and print only the overall verdicta single verdict line0 PASS / 1 REVIEW / 2 FAIL / 3 usagesamples/
python -m pytest sales_engine/tests -q
run the full test suite for this engine10355 passed0 when every test passesnone

Benchmarks

measured demo results
MeasureResult
Engine tests1010,355 tests collected
live collection from the engine directory
Registered controls1121 controls
counted from the registry, not from documentation
Planted defects1222 defect files
every registered control has at least one file that trips it
Control coverage13100 percent of controls with a planted defect
no control ships without a file demonstrating it firing

Control characteristics

engineering

Plain 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

SeverityVerdictAction
No findings above PASSPASScarry the mechanically clean sales file into the documented sales-administration review and sign-off
One or more FLAG, no FAILREVIEWa 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 FAILFAILthe 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

Operating limits

what it refuses to do

See it run

control architecture
Corporate comparison architecture for Unit Sales & Commission Tie-Out: declared inputs feed a deterministic calculation, computed and stated results are compared, and the final output is verified.
The Unit Sales and Commission Tie-Out engine tile states the question that has to hold row by row: every derived column on the Matrix recomputed from the prices beside it, every Commission-Log split summing to the total that row authorised, every sold unit reconciled both ways to the Sold/Close tab, and the rollup recomputed from the Matrix beneath it.

Integration

how to run it

Distribution: public repository, MIT license.

python run.py
python -m pytest sales_engine/tests -q
Source on GitHub Engine README All tests, by engine Run in Codespaces
Substantiation
  • 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