Start a conversationContact

Regional homebuilder and land developer

An operating system built around the business

One operating state the whole company reads from, and a console where the recurring work is run. Every blocker becomes a decision with a name on it, recorded before it is applied.

In production in the client’s environment, operator-run with handoff to the finance team in progress. Verified against the repository and an outside technical review in July 2026.

The shape of the operating systemFour operating centers sit on one operating state, which is compiled into seven named artifacts and built from the company’s systems of record. A record of decisions runs above all four centers. One route is marked: the monthly close, from the accounting system through the operating state into the homebuilding center, and back up into the record.The record of what was decidedDevelopmentHomebuildingLit: the monthly closePortfolio & capitalCommunity & growthOne operating state · seven compiled artifactsOperating stateIndexed excerptsRules of useCoverage reportChange logValidation queueGap auditProject systemAccountingOperator workbooksThe record of what was decidedDevelopmentHomebuildingLit: the monthly closePortfolio & capitalCommunity & growthOne operating state · seven compiled artifactsOperating stateIndexed excerptsRules of useCoverage reportChange logValidation queueGap auditProject systemAccountingOperator workbooks
Four operating centers, where the recurring work is run — the fourth deliberately empty until its datasets arriveOne operating state, compiled into seven artifacts every tool loadsSystems of record, each carrying a freshness caveat that warns when its data is staleOne record of what was decided, and what it was decided on
01

The problem

Land, construction, sales and finance context lived in a project system, an accounting package and the workbooks built around them. The three disagreed about what a lot was, so no number could be trusted without tracing it by hand.

Every recurring deliverable was assembled that way, with no shared place to run the work, no way to see what was blocking it, and no way to tell a computed number from an assumed one.

02

What changed

Three changes, each of which had to hold before the next was worth making.

Before and afterBefore: three systems, each with its own idea of what a lot is, assembled by hand into a deliverable. After: one operating state with one definition, and above it a console listing what is blocking the close — a method no owner has ratified, a missing input, and a source owner who has not signed off.BeforeProject systemlotAccountinglotOperator workbookslotAssembled by handAfterThe console · what is blocking the closeMethod not ratified — the report will not publishMissing input — requested, never estimatedSource owner has not signed offOne operating state · one definition of a lotBeforeProject systemlotAccountinglotOperator workbookslotAssembled by handAfterThe console · what is blocking the closeMethod not ratified — the report will not publishMissing input — requested, never estimatedSource owner has not signed offOne operating state ·one definition of a lot

Three systems, three definitions of a lot.

One operating state, compiled into seven artifacts every tool loads before it runs.

Each recurring deliverable assembled by hand.

Nineteen registered workflows, whose calculations and write paths contain no model call.

A blocked report, and no owner for the blockage.

A queue where each blocker becomes a decision, recorded before it is applied.

No model call on the write path means the same inputs produce the same run every time. A model may draft upstream; what it produces is checked first.

Signing in lands on Operations: what needs a person today, and everything the system can run.

The operating system’s home screen: a panel listing what needs a person today, this morning’s briefing, and the business set out as the parts a team each works on — with its six work-grouped menus across the top on a wide screen, and behind one control on a phone.
The operating system at its actual scope — its destinations grouped by the work rather than by the department that owns the data.Client systemApplication shown with synthetic data
03

Explore the system

Five views of one foundation: three capabilities shown where they need a person, what every tool reads, and one workflow still in development.

Per-lot cost allocation, run as a workflow: six steps, live checks, and a package that holds what it cannot compute.

  1. ResolveScope is resolved against company data: community, phase, lot count, allocation method.
  2. ValidateThe readiness gate runs live. Sales basis, land and direct compute. Indirect stops on a warehouse-to-workbook disagreement; water and warranty are not modeled, and say so.
  3. GenerateThe package is produced with the blocked component held — never filled with a zero or a guess.
  4. ExplainThe summary names the owner of the next action and what should happen next. A model drafts it from the run’s own result over approved read-only tools, and a check verifies every figure against that result; it edits no data.
  5. DecideFinance records which pool to book. Only then is it applied, as a separate, reversible write, from the command center.

The run leaves a per-lot packet, an owner update and a source trace for every value.

Month end. Four communities can report, one cannot, and one reports with a gap — an indirect cost pool forty-one days old, named on the face of the report rather than quietly used. The controller starts with a phase that is ready.

Phase readiness: every community with a readiness verdict and the four cost components as chips, four of them reportable, one partial because its indirect cost pool is out of date, one blocked — and on a wide screen the owner of each gap and the next action beside it.
One month-end carried to a deliverable, with every figure read from company records.Client systemApplication shown with synthetic data
04

What exists today

Deployed, and unfinished in specific places. The places are named.

  • Operating console and queueIn productionFour operating centers, about thirty screens, forty-plus authenticated routes.
  • Deterministic workflowsIn productionNineteen registered. Its own inventory grades eight production-ready, eleven mostly complete.
  • Company knowledge foundationIn productionThe enforced read path. Part of the rule layer is still pending verification against the client’s source documents.
  • Grounded assistantIn productionAnswers from the same state, with a deterministic check after the model.
  • Governed data foundationPartial productionThe warehouse is in production. The staging-first loader is proven in a parity run and not yet landed.
  • Offer reviewIn developmentBuilt and demonstrated. Not in routine use, and its evaluation rules are not settled.
  • EvaluationNot agreedEvaluation suites exist and were run by the operator on a frozen snapshot in May 2026. No measure agreed with the client runs in production.

No usage instrumentation: adoption, hours, cycle time, error rates and dollars are not measured, and nothing is estimated in their place.

05

What it supports, and what it refuses

The boundary is written into the system, not left to habit.

The system

  • Loads the same state before every run, and cites what it used.
  • Refuses a method no owner has ratified, and names who must ratify it.
  • Records a decision as its own act before anything is written.
  • Keeps the prior values, so the write can be reversed.

A person

  • A named source owner signs off before a margin report publishes.
  • Method and reconciliation decisions are a person’s act, recorded first and applied second.
  • An executive decides every offer. The workflow prepares the counter and waits.
  • The assistant explains and cites. It never approves, runs or changes anything.

Because the same state sits under every workflow, the next capability starts from what the last one established.

Bring us a company whose numbers disagree with each other, and the recurring work that keeps being assembled by hand.

Start a conversationadam@bedrockos.co