Runtime architecture · Continuity products

The Project World: A Third, Time-Bounded Kernel

Continuity promises bind at project time. Keep meaning in three joined territories, binding state in operational systems, and every AI claim inside a witness package humans can dispose — on a daily Continuity Build, not a live agent — so the model never silently becomes the system of record.

Scott Farrell · LeverageAI · Architecture extender to the Forward-Deployed Practice OS

The hard question for a continuity product is not “can the model summarise the manuals?” It is: when a national capital-equipment distributor and exclusive importer promises readiness for a named project — these machines, this site, these dates, this exposure — where does each fact live, and what is allowed to change what?

Get that wrong and you do not merely ship a weak feature. You train the organisation to treat AI interpretation as inventory truth, project gossip as schedule fact, and a fluent reserve recommendation as a commercial commitment. The world-model becomes the system of record by drift, not by design.

Consider the ordinary morning that creates the pressure. A customer’s project window is three weeks out. Two machines are mobilising interstate. A supplier email says a control module “should arrive Thursday.” A service history PDF implies an overdue inspection if you read it carefully. Stock in one branch looks fine if you trust last week’s spreadsheet export. The founder still carries the pattern recognition for which failures stop a pour cold — but that judgment is not sitting in a place the organisation can dispatch without calling him. None of these inputs is worthless. Each one is a different kind of fact. Continuity architecture fails when those kinds are forced into a single store and a single authority model.

The commercial object of maintained preparedness — machine passports, dispositions, reserves, bounded response commitments priced against project exposure — is already a product anatomy in its own right. This piece does not re-design that offer. It answers the architect’s question underneath it: how do you structure the knowledge layer so the AI’s world-model never silently becomes the system of record?

What you inherit — and what this piece adds

The Forward-Deployed Practice Operating System already states that the product is a governed join, not a single corpus: firm capability and client context become valuable together while ownership stays distinct, and client information never auto-promotes into firm knowledge without human-gated de-identification and transferability checks. That rule stands. This article does not re-argue it.

What it adds is a refinement forced by continuity work. Continuity promises are not only about “this customer’s fleet.” They bind when a project is declared: mobilisation dates, site consequences, reserved or positioned stock, open inspections, accepted risks, and a readiness state that must be true for a window and then expire. That is not durable firm doctrine. It is not permanent customer history either. It is a third semantic territory.

Three semantic territories, never one company brain

Picture a distributor preparing a customer’s fleet for a major pour window. Three worlds must be joined at decision time — and must remain separable the moment the decision is over.

1. Capability kernel

Durable company knowledge: machine families and configuration rules; parts compatibility and supersession; maintenance practices; known failure shapes; supplier and repair pathways; branch capabilities; evidence requirements; escalation rules; and the things the firm deliberately refuses to recommend. This is what the firm knows how to do, independent of any one customer’s current project.

2. Customer fleet kernel

One private world per customer: enrolled machines and exact configurations; serials; locations; service and parts history; inspections and recertifications; contacts and operating preferences; known supportability issues; existing continuity commitments. This is what is true of this installed base — still not a project schedule.

3. Project World

A bounded, time-dependent world for a particular project:

• project location and operating dates;
• machines being mobilised;
• workload and critical stages;
• expected consequences of interruption;
• required pre-project work;
• critical and wear-parts exposure;
• reserved or positioned inventory;
• freight and branch response paths;
• open questions and accepted risks;
• current readiness state.

The Project World is first-class because commitments live here. It is disposable because the pour ends, the site changes, and last quarter’s positioning plan must not masquerade as permanent doctrine. Client project detail never auto-promotes into firm knowledge; only de-identified, transferable patterns may move upward through a human gate — the same ownership discipline the Practice OS already requires, extended to a third member.

Capability kernel
        +
Customer fleet kernel
        +
Project World
        +
Live inventory / ERP / service / logistics state
        ↓
Purpose-shaped decision world
        ↓
Evidence-backed proposals
        ↓
Human disposition
        ↓
Quote / reserve / purchase / dispatch / inspect / escalate
        ↓
Receipt and write-back

That stack is the governed join made executable for continuity. The AI may read across territories. It does not own them.

The placement table — every fact has a home

This is the load-bearing artefact. If a fact cannot be placed, the architecture is incomplete. If a boundary has no rule, drift will invent one.

Read the table as a placement test. “Supplier lead time for this class of valve is often long” is capability or fleet meaning. “This valve is reserved for Project Parramatta between these dates” is Project World. “Three units are on hand in Sydney after warehouse receipt R-44102” is operational binding state. “We should reserve one unit because configuration B plus prior failures make exposure material” is a witness package awaiting disposition — not yet a reserve, not yet a promise.

Work a few more placements the same way. They train the reflex the table is for:

If your team cannot run this exercise on a real project without arguing, you do not yet have a knowledge architecture. You have a shared folder with ambitions.

Meaning versus binding state

The most important line in the architecture is also the simplest:

AI interprets messy state. Deterministic systems establish binding state.

The wiki — across capability, customer and project territories — holds meaning and relationships:

• this part supports these machine variants;
• this machine is committed to this project;
• this component is critical because its failure stops pumping;
• this supplier usually has a long lead time;
• this substitute was rejected on these serial ranges;
• this customer has paid for exclusive reserve;
• this project requires stock positioned before a particular date.

What the wiki must not become authoritative for: current stock quantity; purchase price; customer price; warehouse receipt; shipment tracking; invoice status; whether a purchase order has actually been approved. Those facts belong in inventory, ERP, CRM, service-management and logistics systems. At decision time the continuity system reads exact stock, price and shipment state from the authoritative source; it does not invent a parallel ledger because the model “seems sure.”

So when someone says “the AI checks whether the part made it to the warehouse,” the strong implementation is not a hopeful re-read of supplier correspondence. It is:

Warehouse receipt event says: arrived
             ↓
deterministic state changes
             ↓
AI explains significance against the project plan

An email saying it should arrive Thursday is evidence of an expectation, not proof of arrival. That contrast is not pedantry. Continuity products sell preparedness. Preparedness collapses the moment expectation is allowed to masquerade as receipt — because the customer hears a promise, the warehouse still has a hole, and the Project World now contains a lie dressed as readiness.

A compressed placement rule that survives the whole design:

AI carries the breadth. Code carries the truth. Humans carry the consequence.

AI does real work — as witness, not oracle

None of this is an argument for a thin chatbot on top of ERP. The AI work is substantial: compilation across emails, manuals, quotes, service records and photographs; reconciliation of machines against parts, project needs against readiness, reserves against failure history; preparation of passports, pre-project work lists, critical-spares matrices and order lines; monitoring of supplier notices, schedule changes and exceptions; memory when a human correction becomes a reusable pattern rather than dying inside the case.

The constraint is structural. Each substantial AI return is a witness package, not a verdict: a proposed claim, supporting exhibits, resolvable pointers, and an honest remainder of what could not be verified. That convention exists so nested interpretation cannot harden silently into organisational fact. This article composes that convention; it does not re-teach its internals.

One package, end to end

Work a single continuity act from intake to write-back. The numbers and part identifiers below are specimen design material from the continuity architecture notes — illustrative of shape, not reported production metrics.

1. Intake. Project World for an upcoming mobilisation shows Machine JXRZ47 enrolled with configuration B. Critical-path analysis flags hydraulic component exposure. A prior comparable failure pattern is already in the capability kernel. Current on-hand is read from inventory, not from chat memory.

2. AI preparation returns a witness package:

PROPOSAL
Reserve part FC-4821 for Machine JXRZ47-5.16HP.

EVIDENCE
• Machine serial record indicates configuration B.
• Parts manual lists FC-4821 for configuration B.
• Two prior failures on comparable machines required this component.
• Current supplier lead time recorded as 31–45 days.

UNRESOLVED
• Physical installed configuration has not been independently inspected.
• Current supplier lead time has not yet been reconfirmed.

DISPOSITION
Accept / Modify / Reject / Inspect first / Escalate

3. Human disposition. Inventory manager accepts the reserve subject to a configuration photo check; commercial owner confirms the reserve fits the customer’s paid continuity tier. The package does not become a warehouse move by self-approval.

4. Deterministic write-back. Only after disposition does code create the reserve in the inventory system, attach the package ID as provenance, update Project World readiness (“reserve approved; inspection still open”), and schedule the lead-time reconfirmation as a monitoring task for the next Continuity Build.

5. Later monitoring. A supplier email arrives claiming Thursday delivery. The build treats it as expectation evidence against the open order — it does not flip stock to “arrived.” Arrival flips only on warehouse receipt. The AI’s next package may propose a contingency if lead time slips; it still cannot invent the receipt.

That is the whole contract in one loop: interpret broadly, bind narrowly, dispose explicitly, write back with provenance.

The human job is disposition, not reconstruction

Someone still prices the service, approves the parts plan and decides what the firm will promise. The job changes from “read everything, remember everything, calculate everything and write the proposal” to “dispose a prepared set of bounded commercial and technical decisions.”

Each decision is its own line item — machine identity correct? part applicable? failure mode material? pool, reserve, position or merely source? downtime consequence justify carrying cost? inspection rather than inference? That is the line-item decision surface: separately disposable judgment units with evidence, typed dispositions, named owners and explicit downstream effects. The underlying redesign pattern is cognitive workflow recomposition: atomise evidence, bound AI judgment, human disposition, deterministic compilation and write-back — not an end-to-end autonomous agent asked to “run continuity.”

The interface is therefore not a chatbot. It is a decision surface — proposal cards in a queue, not a blank prompt.

37 proposed continuity actions
24 ready to approve
7 require commercial modification
4 require technical inspection
2 require founder-level escalation

Those counts are the specimen’s worked morning queue from the architecture notes — again, design shape, not a live dashboard metric. The point is organisational: partial approval, precise correction, named ownership and deterministic downstream effect. Staff do not navigate ten systems to discover that something changed. They meet a typed queue where most items are cheap to accept and a minority carry the real judgment load.

Operate it as a Continuity Build

Most of this should run asynchronously. A live autonomous agent “owning” continuity is the wrong default: it collapses review into chat, blurs binding state into conversation, and makes rollback a folklore exercise.

Every day — or more often for active projects — the system compiles changed evidence:

New customer evidence
New service requests
New supplier emails
Inventory changes
Purchase-order state
Warehouse receipts
Shipment updates
Project schedule changes
Machine additions or removals
Human corrections
        ↓
Continuity Build
        ↓
Changed exposure and action packs

The daily build emits versioned, diffable packs: what changed; which machine or project is affected; evidence; newly exposed risks; actions proposed; actions already completed deterministically; items waiting on the firm; items waiting on the customer; decisions that have gone stale. That is the nightly decision-build discipline applied to continuity — production artefacts, not “AI magic.”

A staff member arrives to something like:

PROJECT: major hospital pour window
• Reserved hydraulic valve received at Sydney warehouse — no action.
• Supplier moved pump-control module ETA from 9 to 24 days.
  Proposed response: position existing Brisbane stock in Sydney.
  Requires: inventory manager approval.
• Machine JJ-104 maintenance record now indicates inspection overdue.
  Proposed response: book pre-project inspection.
  Requires: service manager approval.

Notice the first line. Warehouse receipt already updated binding state. The build reports it; nobody re-types stock into a wiki. The second line is still a proposal because repositioning commits capital and logistics. The third is technical authority, not model authority. The Continuity Build is how the organisation keeps a maintained readiness state without pretending a chat session is a control plane.

The morning job design follows from the pack, not from heroic system navigation:

• Inventory / logistics dispose positioning, reserves and supplier contingencies that touch stock and freight.
• Service dispose inspections, pre-project work and technical substitutions that touch safety or machine readiness.
• Commercial owners dispose price, margin, exclusivity of reserve and what may be promised in writing to the customer.
• Founder-level escalation is reserved for the thin tail — novel failure shapes, brand-level risk, or commitments the firm has no prior fossil for — not for routine part matches.

That layering is deliberate. If every item escalates to the founder, you have not built a product; you have built a more elaborate way to interrupt the same person. If nothing escalates, you have probably let the model invent authority. The specimen queue shape — most items ready to approve, a commercial minority, a technical-inspection minority, a rare founder-level escalation — is a design target for residual human scarcity, not a claim that any live system already hits those ratios every day.

Versioning matters as much as the queue. Yesterday’s pack and today’s pack should be diffable: which exposures opened, which closed, which recommendations flipped, which human corrections entered the next compile. Without diffs, “AI monitoring” becomes a mood. With diffs, continuity operations start to look like production software — which is the point of borrowing the nightly-build discipline rather than inventing a mystical agent runtime.

How the frameworks compose at this join

This extender’s claim is composition, not a new religion:

• Practice OS supplies the governed join and the ban on collapsed ownership.
• Project World (this piece) supplies the time-bounded third territory where continuity commitments actually bind.
• Witness Not Oracle supplies the return contract for every substantial AI act.
• Line-item decision surface / Decision Navigation UI supply the human work shape: dispose prepared units, don’t reconstruct worlds.
• Nightly AI Decision Builds supply the operating cadence specialised here as Continuity Build.
• Preparedness as product supplies the commercial object this runtime is for — referenced, not redesigned.

If any layer is missing, a different failure appears. Without Project World, commitments smear into fleet notes. Without the binding-state boundary, the wiki becomes the stock system. Without witness packages, early guesses harden. Without a disposition surface, the organisation cannot adopt partial truth. Without a build cadence, someone reopens ten systems every morning and calls it process.

What you can do with this

The customer-facing sentence still does not need to mention AI. For a national capital-equipment distributor and exclusive importer of a critical brand, the promise is that the firm maintains a current continuity plan for enrolled fleet and major projects — readiness, supportability, critical spares, response pathways and unresolved exposure made explicit. The founder’s judgment still matters at escalation points; it is no longer required to reconstruct the entire world on every incident.

Two objections arrive reliably. First: “Isn’t this just more process before the model can help?” No. The model is already doing the expensive breadth — compilation, reconciliation, monitoring. The process is the thin authority surface that makes that breadth adoptable. Enterprises do not adopt monolith answers they cannot dispute in parts; they adopt queues of line items with evidence. Second: “Can’t a good agent keep the ERP and the wiki in sync live?” It can try — and the failure mode is exactly the one this piece designs against: silent writes, expectation treated as receipt, project gossip promoted into firm truth, and no versioned pack anyone can audit on Monday. Asynchronous builds with human disposition are not a nostalgia for batch processing. They are how you keep AI on the interpretive side of the binding-state boundary.

Architects should hold a colder standard. If the AI’s interpretation can change stock, price, receipt or promise without a human disposition and a deterministic write, the world-model has already become the system of record — regardless of how carefully the prompt is worded. Carefulness is not tenancy. Tenancy is engineering. The Project World is how continuity earns a place in that engineering without pretending project time is permanent truth.