The open defect ledger
Honesty without flattery is the whole point, so the defects we know about are listed here — plainly, with their causes — and each stays listed until a future baseline resolves it. The frozen 1.0 numbers are never edited in place; a fix always means a new, fully re-run baseline. Issues found by the living farm (the model that keeps running) are tagged accordingly.
The engine's acquisition safety gate checks an organization's cash against its current monthly operating costs — but nothing prices the incoming carrying costs of the properties being acquired. During the startup grace window (when current costs are payroll-only), a rare week-one ladder of attractive listings lets an organization legally commit ~92–96% of its capital before its first rents arrive. Every purchase is individually legal under the released gate; the failures are purely institutional — zero evictions, no rent hikes, no tenant harmed on the way down.
Version history. v1 (current): affected. The full census as the living farm found it — standard series: 2 failures at $5.5M (months 3–4), 1 at $6.0M (month 5), 1 at $5.0M (month 4), 1 at the $4.5M extension rung (month 5); deep-discount series: 2 at $5.5M (months 3–4), the same seeds as the standard pair — the gap is independent of rent policy, because it lives on the buy side. Each failure was replayed to the penny to confirm the mechanism: 6–7 properties bought in the opening weeks, acquisitions accounting for 92–96% of every dollar spent, zero gate refusals. v2 (next baseline): remediation expected — a forward-looking gate that prices in-pipeline obligations, including expected onboarding costs, before committing.
Reproduce it on v1 today: restore the published Gold backup and run
simulation.py --projection-id 201 --seed 128 --months 240 (dies month 3) or
--projection-id 200 --seed 247 (dies month 4). Verify the fix when v2
ships: the same commands on the v2 baseline should carry the same organizations to
month 240 without insolvency — that claim publishes here, checkable, the day the v2 engine does.
Massachusetts law requires lead remediation ("deleading") for pre-1978 rental housing, and about 99.6% of Salem's stock is pre-1978 — so for this portfolio deleading is the norm, not the exception. In the 1.0 engine the abatement step is unreachable: a work-classification bug leaves it as dead code, so across the entire released corpus it fires zero times. The consequence is that 1.0 never charges the deleading a real pre-1978 acquisition would legally incur, so its operating costs — and therefore its survival numbers — are optimistic on this one axis. No tenant is affected; the gap is purely an unmodeled cost.
Version history. v1 (current): affected — abatement is dead code, zero work items in the corpus, deleading cost absent. v2 (next baseline): remediation expected — the lead chain is made reachable and recalibrated to Massachusetts DPH / MassHousing figures (KD-043), and the risk assessment is moved to due diligence, so the organization prices the actual abatement cost before it commits and can decline a property it cannot solvently carry (KD-193). Making lead real surfaced that a cost committed blindly after closing would itself sink mid-size organizations — which is precisely why the assessment now happens before the purchase, not after.
Reproduce it on v1 today: restore the published Gold backup, run
simulation.py --projection-id 206 --seed 99 --months 240, and query
simulation.ComplianceWorkItem WHERE WorkType = 'LEAD_ABATEMENT' — zero rows. Verify
the fix when v2 ships: the same query on a v2 run returns calibrated lead-abatement work items,
and the acquisition ledger shows lead priced at due diligence — that claim publishes here, checkable, the
day the v2 engine does.
v1 results are reproducible to the cent on the pinned environment — the published Gold backup, the published engine, the documented SQL Server setup. That was verified before release and still holds. What we have since found: a handful of internal queries feed random draws to entities in whatever row order SQL Server returns, without an explicit ordering. On the pinned environment the query plans are stable and every same-seed run is identical. On a materially different environment — a newer SQL Server, different statistics or indexes — the optimizer may legally return rows in a different order, and a same-seed run can then take a different but equally valid path through the model. Neither path is wrong; the run would simply no longer match our published run byte-for-byte.
If you are reproducing v1 exactly, use the pinned environment as documented in REPRODUCE. The v2 engine removes this at the root: every order-sensitive query imposes an explicit deterministic ordering, enforced by a tracked determinism gate that includes a negative control — a test that demonstrably fails on the defect it guards against. We found this with our own validation tooling and are disclosing it because reproducibility claims should say precisely what they claim.
The 1.0 engine charges tenants from BaseRent while acquisition underwriting uses
AdjustedRent. In the released model this is acquisition-scoring-only — no tenant rent
and no published survival number is affected — and in at least one case it undercharged
tenants. Ruled for the next baseline's engine rework.
The synthetic rent generator prices a half-bath at 7.5% instead of the intended 5%. Acquisition-scoring-only in 1.0; no tenant rent and no published survival number moves. Ruled for the next baseline.
Full engineering detail for every issue lives in the project's development tracker and the baseline-of-record documents shipped in the repository. Nothing is ever removed from this ledger, and every issue keeps a version history: what was wrong in the version that shipped it, and what fixed it in the version that did. When a new baseline resolves an issue, its card keeps a note showing how to reproduce the defect on the old version and how to verify the fix on the new one — the fix claim ships only when it is checkable.