Structure Phase Watch: Live Production, Crane and Delivery Evidence for Every Pour on a Construction Site

A Slip Shows a Week After It Begins

The joint venture discovers schedule loss and safety exposure after they have already cost the program, because the evidence of both is captured but never joined.

The abstract states the design in one paragraph and Figure 1 sets the whole shape on one page. This chapter opens the problem that shape answers: the question the joint venture needs answered continuously, the documented cost of answering it a week late, and the operation, described by class, that holds the evidence.

1.1  The Question, the Data and the Regulatory Ground

The operation needs one question answered every morning: is the structure phase about to slip, and where is the exposure that will cause the next injury? Answering it requires joining four streams that today never meet: precast production against the pour sequence, which means cast dates, curing state and quality release for every unit; crane utilisation against the lift plan, which means planned lifts per crane set against the loads, radii, wind stops and alarms the cranes actually logged; truck flow, which means gate movements, queue depth at each gate, and tracker position against each assigned delivery window; and the people and equipment conflicts, which means permits, workforce presence by zone, and entry into a crane slew radius or an exclusion zone under a suspended load. Beneath all four sits the schedule of record: planned dates, float and pour and lift codes in the owner's baseline and the joint venture's own fragments of it. The regulatory ground is layered. Work must satisfy the Saudi Building Code, the occupational safety regulations of the ministry responsible for labor and social development, and the project owner's HSE standard, which the joint venture works to contractually. The summer midday work ban, from noon to mid afternoon between mid June and mid September, removes three working hours from every outdoor crew, which tightens every delivery window the sequencing logic will touch and makes morning surges unavoidable. Data discipline itself is becoming a formal regime on projects of this class: industry guidance now expects a written data management plan before project data is collected and shared (AGS 2024), and major public owners treat data management for investigation and monitoring data as an explicit contractual requirement (ARMY 2025). A design that leaves the record fragmented inherits those obligations without the controls that satisfy them.

1.2  The Documented Cost

The cost of fragmented site data is documented, and it lands twice. First as schedule loss that compounds quietly: a slip that begins on a Monday and surfaces at the Thursday look ahead has already consumed its curing time, its idle crane hours and its queue delay, and the evidence of why it began has been cleared away with the queue. Second as legal and regulatory exposure over data the firm already held. A court in the United States sanctioned a civil construction contractor with an adverse inference for failing to preserve electronic data from five custodians, converting an operational dispute into a case outcome the contractor could not defend (Minerva26 2023). A privacy watchdog in South Korea fined a construction equipment firm over an employee data leak, a penalty that attaches to the handling of workforce records rather than to any physical failure (YNA 2026). Both failures are of the kind this design is built to prevent: evidence captured but never joined, kept or controlled.

1.3  The Operation as a Scenario

The scenario is a precast and site logistics joint venture on a giga project in the Riyadh region: a mixed use district of roughly two square kilometers in its heavy civil and structure phase. The joint venture runs one precast yard casting hollow core slabs, facade panels and stair units; one batching plant; more than a dozen tower cranes and half a dozen crawler cranes spread across four work zones; a fleet of flatbed and mixer trucks in the tens on a single internal haul road a few kilometers long; and a workforce in the thousands across its own crews and about a dozen subcontractors. Six role groups live inside this evidence every day: a planning manager with a small planning team owning the look ahead; a crane coordinator with lift supervisors; a yard manager with a quality lead; an HSE manager with officers; a logistics controller working the gates; and the subcontractor supervisors whose crews occupy the zones. The physical environments are demanding: open air zones with dust, glare and summer ambient heat that degrades lenses and electronics; gates and laydown areas where mains power is scarce, so sensing runs from solar powered enclosures; and tower crane slew zones whose suspended loads cross the same ground the workforce occupies. The counts that size the design are twelve named source systems, six role groups, and a place set of four work zones, one precast yard, one batching plant, the main gates, the laydown areas and the haul road.

Every Site System Sees One Slice of the Phase

Each existing system holds a true fragment of the structure phase, and the answer to the slip and exposure question lives in the fragments none of them share.

Chapter 1 defined the question and the operation that holds the evidence. This chapter shows why the operation cannot answer the question today: every system holds a true fragment of the structure phase, and the answer lives in the fragments none of them share. Figure 2 sets each system's sees and misses side by side.

2.1  What Each System Sees, and What It Misses

The schedule of record, Primavera P6, sees planned dates, float and pour and lift codes for the owner's baseline and the joint venture's fragnets; it misses everything that happens between exports, so a slip exists there only after someone edits the plan to match reality. The precast register spreadsheet sees cast dates, curing state and quality release for every bed and unit; it misses the pour and the crane waiting on the unit, so a curing delay looks like a yard number with no downstream consequence. The batch plant SCADA sees every ticket, with mix design, batch time, temperature and quantity against a target pour; it misses erection, so a slow pour cycle leaves no trace of the delivery chain that caused it. The Excel lift schedule sees planned lifts per crane; it misses what the cranes actually did, which lives in the anti-collision systems' logs of load, radius, wind state and alarms. The haulage contractor's GPS portal sees where the tracked trucks are against their windows; it misses the gate queue and the untracked mixers. The paper gate logs see one line per movement; they miss anything until a hand transcribes them, and no process joins them to a window or a crane. Crawler crane telematics sees hours, location and fault codes but has no planned-lift denominator. The HSE document system sees yesterday's forms, never a live breach. The biometric turnstiles see presence at the main gates but not which zone, permit or load path each worker was exposed to. The weather station sees wind and temperature but not which lift each reading stopped. The paper permits see who may work in a zone but not the conflicts between overlapping permits and crane operations.

2.2  What None of Them See Together

What none of them see is the same event three times: panel curing running behind at the yard, a tower crane idle through a large fraction of its shift waiting for deliveries, and the haul road gate backed up with a queue of trucks because two zones called the same delivery window. Those are three records of one failure in delivery sequencing, and no existing system can hold them together. The cost in practice is precise: the slip is discovered at the Thursday look ahead a week after it began, and HSE learns of a crane or truck near miss from a form filed the next day, when the laydown area that produced it has already reset for the next morning's surge.

Four Constraints Shape the Live Structure Phase Model

Sovereignty over the record, no replacement of systems of record, decisions reserved to named people, and a cheap first gate define what the design may do before any architecture is chosen.

Chapter 2 showed the fragments and the cost of never joining them. This chapter fixes the four constraints the join must respect before any architecture is chosen, because each one is hard in this industry for a specific reason.

3.1  The Record Stays Sovereign

Every weight, every detection and every decision record stays on joint venture hardware in the site data room, inside the Kingdom, beside the record it reasons over. This is hard because the convenient path runs the other way: hosted model services and off-site analytics are one contract signature away, and the temptation grows with every capability the design adds. It is also hard because the record is personal: biometric turnstile data identifies individual workers across about a dozen subcontractors, and workforce data handling now carries regulatory penalty exposure in this industry, as a recent fine over an employee data leak at a construction equipment firm shows (YNA 2026). Contracts on projects of this class increasingly carry explicit data safeguarding duties, which makes the boundary a contractual fact as much as a technical one (Acquisition n.d.).

3.2  No System of Record Is Replaced

The design reads every source and writes back to none of them. Primavera P6 stays the planning team's tool with the owner's baseline untouched; the casting register stays the yard's spreadsheet until the joint venture itself decides otherwise; the paper permit keeps its legal force. This is hard because a read-only posture must still earn daily use from people whose own tools keep working, and because data management guidance treats source systems as governed records whose custody and quality are owned, not bypassed (AGS 2024). The only write path in the whole design is the object model the joint venture owns, which accumulates the joined record without editing a single source.

3.3  Every Decision Stays with a Named Person

Re-sequencing deliveries, accepting a slip forecast and closing a breach all end at a named person: the crane coordinator, the planning manager, the HSE manager. This is hard because the moment of value is the 06:00 delivery surge, exactly when a human approval loop is most tempting to automate away, and because a recommendation that arrives without a clear owner tends to be either ignored or obeyed blindly, and neither is accountability.

3.4  The First Gate Must Be Cheap to Stop

Phase one proves the joint venture's own hypothesis, that recoverable loss is crane idle time caused by delivery sequencing rather than crane count, on one zone, across nine items, behind one exit gate. This is hard because construction pilots habitually scale before they prove, and a design that cannot be stopped cheaply at its first gate has not been scoped honestly.

3.5  Scoping Decisions

Three decisions set the boundaries within which the rest of the design follows. Table 1 states what each buys and what each costs.

3.6  What the Design Chose Against

Each rejection below was made for a stated reason, not by omission, and the last row records what is out of scope entirely. Table 2 sets them out.

One Stack Runs From Gate Log to Look Ahead

Systems of record sit below, one object model holds the middle, and the services and surfaces the planners and HSE officers use sit above, so a single pattern carries the whole design.

Chapter 3 fixed the four constraints the design must honor: the twelve systems of record stay in place untouched, every byte stays inside the joint venture's own perimeter, every re-sequencing output remains a recommendation a named person approves, and the first gate can stop the work cheaply on one zone. This chapter shows the single architectural pattern that satisfies all four at once, and names the components at every stage of the stack.

4.1  Records Below, One Model in the Middle, Decisions Above

The design is a three-layer pattern. Below sit the systems of record: the owner's Primavera P6 baseline, the batch plant SCADA, the casting bed register, the lift schedule, the gate logs and the rest, all left exactly where they are and all read only. In the middle sits one object model that holds the fifteen typed objects of the structure phase and the links between them. Above sit the eight services that read that model and the six surfaces where the planning team, the crane coordinator, the yard manager and the HSE officers make their calls. Figure 3 shows the layered stack with the component counts per layer: twelve sources, three adapter families, fifteen objects, eight services and six surfaces, on JV hardware in the site data room. The pattern fits because the problem defined in Chapter 2 is a join failure, not a missing feature in any one system. Point-to-point integrations would multiply the join problem by pairing systems two at a time; a shared object model pairs every system once, against the model. The same pattern also serves the sovereignty constraint: because the middle layer is the only place systems meet, the perimeter needs only one defended interior rather than a mesh of connections, and because no adapter ever writes back to a source, the systems of record carry no new risk.

4.2  The Stack Stage by Stage

Each stage of the stack owns one job and hands a defined artifact to the stage above it, from raw records at the bottom to the six decision surfaces at the top. Table 3 names the components at every stage and states what each is responsible for and how it does it.

Fifteen Objects Turn Site Data Into One Argument

Cranes, units, tickets, trucks, permits, workers, zones and pours become typed objects whose links let one query reach the story behind any slip, with every write passing through a person.

Chapter 4 placed one object model in the middle of the stack. This chapter opens that model: the fifteen objects it holds, the typed links that let a query cross from a delayed pour to the crane that waited for it, the place a person sits in every write, and the hosting posture that keeps the whole thing inside the joint venture's boundary.

5.1  Fifteen Objects and the Typed Links Between Them

The model holds fifteen objects in five kinds. Four are assets that do the work: tower_crane for the 14 tower cranes and crawler_crane for the 6 crawler cranes, casting_bed and precast_unit for the yard's output, and truck for the 60 vehicle fleet. Four are records: batch_ticket from the plant SCADA, p6_activity from the owner's baseline and the joint venture's fragnets, permit from the paper permit to work system, and hse_observation from the incident and observation forms. Four are events: gate_movement, delivery_window, lift_plan_entry and pour. One is a person, worker, anchored in the biometric turnstiles, and one is a place, zone, covering the four work zones. Figure 4 draws every object and every typed link between them, with the pour as the focal object because the pour is where schedule and safety meet. The links are what make the model an argument rather than an archive. Start at a pour showing status Delayed and the query reaches the batch tickets behind it, the precast units and their casting beds and curing state, the p6_activity that carries the float, the delivery_window objects and the trucks and gate_movements that explain whether the delay arrived by road, and the tower cranes and lift_plan_entries that show what idled while it waited. The same query continues into the zone, the permits active there and the workers present, which is the exposure picture an HSE officer needs. A document store can hold each of these records but cannot traverse between them, so each answer would be a separate search in a separate system; here one query reaches the whole story, which is exactly what the Thursday look-ahead meeting cannot do today.

5.2  Where the Human Loop Lives and How the Model Is Hosted

The human loop sits at the only write path into the model that changes an operational plan. Every re-sequencing output, every proposed delivery window and every recommended look-ahead draft is a recommendation; the planner or the crane coordinator approves it, and the approval, the approver and the reasoning are recorded with the decision. Breach detections behave the same way: the system raises the alarm while it happens, and the HSE officer confirms, dismisses or escalates it, so the model never closes a gate or stops a lift on its own. The hosting posture follows the constraint set in Chapter 3. All fifteen objects live on the joint venture's own servers in the site data room, with the Riyadh office as the second site and the owner's sovereign cloud region held as a later alternative, so no object, clip or embedder output leaves the Kingdom. Identity runs through Keycloak with a role per surface, and the employee data the model holds is exactly the class of record whose leakage draws regulator fines elsewhere in the industry (YNA 2026), which is why the perimeter, the roles and the retention rules are design constraints rather than settings. External links are bounded: camera clips are referenced by identifier and stored inside the perimeter, and the only outbound integration is the read of the owner's P6 export. The data management discipline the model enforces, one schema, one clock, one provenance tag per record, follows the same structured plan-first practice published for engineered projects (AGS 2024).

5.3  One Object in Its Recorded Form

The tower crane object shows the recorded form the other fourteen follow: an identifier, a label, a kind, typed properties, a closed status vocabulary of five states from Planned lift to Out of service, and links to the lift schedule entries and anti-collision events that feed its utilisation figure.

{
  "id": "tower_crane",
  "label": "Tower crane (TC-01 to TC-14)",
  "kind": "asset",
  "anchored_in": "Excel lift schedule",
  "properties": [
    "Crane ID (TC-07)",
    "Load and radius from the anti-collision system",
    "Wind interlock state",
    "Alarm events",
    "Shift utilisation"
  ],
  "status_vocabulary": [
    "Planned lift",
    "Lifting",
    "Idle waiting for delivery",
    "Wind stopped",
    "Out of service"
  ],
  "links": [
    {
      "to": "lift_plan_entry",
      "label": "executes"
    }
  ]
}

Each Source Enters Through an Adapter

Twelve systems of record enter through three adapter families onto one event backbone, so a paper gate log and a batch ticket arrive with the same guarantees.

Chapter 5 defined what the object model holds and who may write to it. This chapter describes how data reaches it: which twelve systems enter, what the three adapter families guarantee on the way in, and what the event backbone does with every event once an adapter has published it.

6.1  Twelve Sources, One Integration Map

Twelve named systems feed the model, and Figure 5 maps each one to its adapter path. The owner's Primavera P6 baseline and the joint venture's fragnets arrive as daily XER or XML exports from the planning team, with the REST API held as an upgrade behind an owner consent checkpoint. The batch plant SCADA of the Command Alkon style is integrated as a read-only historian mirror on the joint venture's own network, so no OT zone is crossed. The casting bed register and QC release spreadsheet, the Excel lift schedule and the paper gate logs enter through the file and doc adapter family, the gate logs after the one zone's paper digitisation in phase one. The haulage contractor GPS portal and the 20 proposed trackers for the untracked mixers enter through the telemetry family, as do the crane anti-collision systems of the SMIE and AMCS style, the crawler crane telematics, the site weather station and the biometric turnstiles. The HSE document system and the paper permits to work enter through the integration and file and doc families respectively. Every source carries the same provenance class, an operator system of record, and every integration is read only, so the design changes no system it depends on.

6.2  What the Adapter Tier Guarantees

Each adapter family makes the same five guarantees regardless of what it reads. It normalizes its source into the one schema of the target object, so a paper gate log line and a GPS ping both become events a single query language can join. It stamps every event with a source timestamp resynchronized against the site grandmaster clock, because a join between crane alarms and gate times is worthless if the two clocks disagree by minutes. It carries provenance on every event: source system, adapter family and the record identifier in the origin system, so any figure on any surface can be traced back to the record it came from, the traceability that formal data management guidance for monitored works demands (ARMY 2025). It replays idempotently, so re-reading a day of P6 exports or a resubmitted spreadsheet produces no duplicate objects. And it handles schema drift in the spreadsheets explicitly, quarantining a malformed register rather than silently mis-typing a curing date.

6.3  The Event Backbone

Everything an adapter publishes lands on Apache Kafka 4.3.x running in KRaft mode with three dedicated controllers inside the site data room. Ordering is by event key, so all events for one crane, one truck unit or one gate arrive in sequence and the utilisation and queue calculations never see time run backwards. Delivery is at least once with idempotent consumers, which pairs with the adapters' replay guarantee to make the backbone safe to restart. Buffering follows the failure mode the project itself named: the edge nodes buffer hours of private LTE disconnection before forwarding, sized generously, so a patchy link under a crane zone delays a stream rather than losing it. Replication keeps three copies of every topic across the data room cluster with retention long enough that the Thursday look-ahead can replay the full week, and because the whole estate sits inside one joint venture perimeter, no event crosses a boundary on its way from a gate log to a planner's screen.

Detection Runs at the Edge and Reasoning Stays in Country

Camera detection and counting run on solar powered edge nodes where the connection is weakest, forecasting and the work surface run on the operator's own servers, and only compact events cross the boundary.

Chapter 6 closed the path from source to backbone: every system enters through an adapter and lands as ordered events on the streaming layer. This chapter places the compute that watches those events, because where a model runs decides whether a breach alert survives a dropped link.

7.1  Three Tiers, Each Placed Where Its Work Is Cheapest

Figure 6 shows the three inference tiers. The lowest tier is the edge: Jetson Orin industrial edge class compute in solar powered IP66 enclosures with NUT managed UPS and sunshields, placed at the main gate truck queue, laydown area east, the crane TC-07 slew zone, the batch plant loading bay and the haul road junction. Each node runs detection and tracking locally under K3s: RF-DETR served through ONNX Runtime finds flatbeds, mixer trucks, workers, precast panels, suspended loads and tower cranes, and the ByteTrack class tracker holds identity across frames for queue counts, dwell and slew radius entry. Frigate NVR records beside it. The edge exists because private LTE coverage at laydown areas and under crane zones is patchy: detection at the point of risk must not depend on a stream that drops. The middle tier is the site inference server in the site data room, eight L40S class PCIe GPUs of 48 GB class each. It runs Chronos-2 forecasting over the series held in InfluxDB 3 Core, BGE-M3 embeddings for retrieval across permits, forms and work surface queries, and the cross zone aggregation behind live breach detection. The top tier is one node of eight 141 GB HBM GPUs (H200 class) serving GLM 5.3 for the agentic work surface. The arithmetic is the register's: 753 billion parameters at FP8, one byte per parameter, give 753 GB of weights; multiplied by 1.2 for KV cache and activations, the node must hold 904 GB; its 1,128 GB holds that, leaving about 224 GB of headroom that covers concurrent planner sessions rather than weights. The frontier weights sit on JV hardware inside the Kingdom beside the record they reason over, and the 141 GB HBM class ships to Saudi Arabia only under a US export licence, so the frontier node's order date is a phase one checkpoint on the licence timeline.

7.2  The Latency Budget

Three clocks govern the design, and each is set where its work runs. The breach clock is an edge clock: camera frame cadence at the node, alarm raised locally, the uplink notified afterwards, so no network condition delays an alert about a worker inside a slew radius. The forecast clock is a site clock: Chronos-2 refreshes the slip picture daily against the P6 export and continuously against the streaming telemetry, and a three day horizon only has to beat the Thursday look ahead, not the second hand. The reasoning clock is a local area network clock: work surface prompts round trip to the H200 node in the same building as the object model, with no public internet hop, which is what makes an interactive session over a 753 billion parameter model practical on JV hardware.

7.3  What Crosses the Boundary and What Fails

What crosses from edge to data room is compact: detections, counts, tracker identities, alarm states and buffered telemetry samples, not continuous video. Video stays on the node, and a clip leaves only as a referenced artifact on an HSE form. When the link fails, the buffered uplink is sized for hours of disconnection and then doubled; local inference continues, so the gate keeps counting a queue it cannot yet report. When power or heat fails, the NUT managed UPS rides through interruptions, the enclosure thermal budget including solar gain is engineered before installation, and internal enclosure temperature is monitored as a first class signal, because dust, glare and 50 C summer ambient present as accuracy loss before they present as outages. When the update path fails, nothing breaks: Harbor holds container images and MLflow holds model versions in the air gapped registry, nodes run the last promoted version, and a new model reaches the edge only through that registry, never through the internet.

The License Decides What the Operator Can Own

Five models carry the design, and each is chosen so the joint venture can hold its weights, fine tune them and keep every output inside the site data room.

Chapter 7 placed the compute: detection at the edge, forecasting and aggregation in the data room, one frontier node for reasoning. This chapter names the models that run there and the licenses that make owning them possible.

8.1  The Frontier Language Model and Its License

Figure 7 shows the model stack. GLM 5.3 open weights is the register's one frontier class model, at 753 billion parameters filed, run at FP8 on the single H200 class node in the site data room. Its role is the agentic work surface and ontology maintenance: the planning manager and four planners, the crane coordinator and lift supervisors, the yard manager and QC lead, and the HSE manager and officers build and run their own checks and daily agents on the live structure phase model, for example a daily agent naming every crane under 50 percent utilization and its cause. The license is a bespoke GLM-5.3 license that permits commercial use, fine tuning and redistribution, which is what lets the JV hold and improve its own copy. Its one trigger, a security review for a model as a service business above USD 10 billion group revenue in twelve months, does not apply to internal JV use; the corporate group position is confirmed at contracting and the attribution notice is recorded.

8.2  Vision, Tracking, Forecasting and Retrieval

Four open models carry the rest. RF-DETR is the detection and segmentation model, Apache-2.0 licensed across the rfdetr package and its Nano to Large detection checkpoints, fine tuned on site footage and served on the edge nodes through ONNX Runtime and at the site tier: it finds the flatbeds, mixer trucks, workers, precast panels, suspended loads, tower cranes and truck queues the design watches. It was chosen against a packaged site safety vision product because the packaged product rents the exact weights the sovereignty clause requires the JV to own and harden. The Roboflow trackers library, a ByteTrack class tracker under Apache-2.0, supplies motion only identity for queue counts, laydown dwell and slew radius entry, chosen over the BoxMOT collection to avoid AGPL exposure. Chronos-2 is the universal forecasting model, Apache-2.0 with no field of use restriction, so weights may be held, fine tuned and redistributed; it turns the InfluxDB series into the three day pour slip forecast, gate queue projections and utilization trajectories. BGE-M3 is the hybrid multilingual embedder under MIT, running from the device tier to the site tier: a workforce whose records carry language tags across the JV and its 11 subcontractors needs retrieval that spans permits, HSE forms and work surface questions in more than one language. Holding worker records inside the boundary is more than a preference; a privacy regulator fined a construction equipment maker 73.5 million won over an employee data leak (YNA 2026).

8.3  The Model and Equipment Register

Table 4 collects the register: each model, each hardware class and sizing rule, the sensing the design stands on, the patterns it follows, and the ground it runs on. The discipline the register records is the one public guidance asks of engineered projects: state what data exists, who holds it and under what terms (AGS 2024).

Shadow Mode Comes Before Any Flag Is Trusted

Three phases with counted items and hard gates prove the slip forecast and the breach detection against the record before anyone acts on a flag.

Chapter 8 fixed the models, their licenses and the hardware classes they run on. This chapter sets out how the design earns the right to be trusted: three phases with counted items, workstreams and hard exit gates, so the slip forecast and the breach detection are proven against the record before anyone acts on a flag, and the work can be stopped cheaply if a gate does not hold.

9.1  Three Phases, Counted and Gated

Figure 8 shows the rollout as three phases with item counts, workstreams and exit gates. No phase carries a duration; each phase ends when its gate is met, not when a calendar page turns. Phase 1 is a one zone pilot carrying nine items across five workstreams: camera and edge detection, HSE live breach detection, records and permits, the sovereign platform and the structure phase model. The items integrate Primavera P6, the yard register and the batch plant feeds, digitise one zone's paper records, mount the first edge nodes and stand up the ontology. The exit gate is the built structure phase ontology: every object from Chapter 5 instantiated for one zone, with its sources joined and its provenance classes recorded. Phase 2 carries six items across five workstreams: the agentic work surface, camera and edge detection, forecasting, logistics re-sequencing and records and permits. Its exit gate is the forecast: pour slips predicted three days out against the P6 record, shadowed so planners see the forecast but the schedule of record is untouched. The delivery re-sequencing console and the work surface launch inside this phase, both in recommendation-only mode. Phase 3 carries three items across three workstreams: the agentic work surface, logistics re-sequencing and the sovereign platform. Its exit gate is the drafted weekly look ahead: the Thursday meeting reads its first draft from the record rather than assembling it from four systems by hand. Model governance and retraining become standing operations here. Requirement coverage is counted, not asserted: of the seven recorded requirements, two are covered by the gates above, none is partial, and five sit outside this baseline as later scope the JV may take up.

9.2  What the Rollout Measures

The rollout measures five things against the record. First, slip forecast quality: every three day forecast is scored against what P6 shows happened, by pour and by zone. Second, crane idle time and its attributed cause: the share of a shift each tower crane spends idle waiting for delivery, and how much of it the re-sequencing console removes when its recommendations are accepted. Third, gate flow: queue depth counted by camera against the paper log baseline, so the digitised record can be audited against what the gate actually did. Fourth, breach detection: every live flag is reviewed by an HSE officer, giving precision per detection class and the time from breach to alert. Fifth, exposure during the delivery surge: worker and suspended load co-presence in laydown areas between 06:00 and 08:00, counted before and after re-sequencing goes live.

9.3  What Fails and What the Design Does

Table 5 lists the failure modes the design carries and its answer to each.

9.4  Lessons

Shadow the flags before anyone trusts them. Every flag in phase 2 is advisory: the forecast is scored against P6, the breach detection is scored by HSE review, and the re-sequencing console proposes while the crane coordinator decides. Trust is earned per detection class, and a class that cannot hold its precision stays shadowed. Data management discipline from adjacent engineering practice supports this: plan the record before the analysis, so every flag can be traced to the data that produced it (AGS 2024). The gate camera is the fallback, not the other way round. The GPS feed is richer than pixels, but its format is unconfirmed, so the design treats camera queue counting as the guaranteed floor and the feed as the upgrade. A design that needs an unconfirmed feed on the critical path is a design that stops on the first integration surprise. A license trigger is a contracting question, not an engineering one. The GLM 5.3 review trigger turns on a business model the JV does not run, but the corporate group position still has to be confirmed and recorded at contracting, with the attribution notice filed beside the model registry.

9.5  What Is Still Open

Five questions remain open. Whether the owner consents to direct P6 API access: settled, it would raise the schedule join from daily files to near live and let the fragnet read flow both ways. Whether the GPS feed arrives in a usable format: settled, it would remove the camera fallback for 40 tracked trucks and tighten delivery window attribution. Whether the reuse survey passes at zone edges: settled, it would cut new camera count and phase 1 cost. Whether the corporate group position triggers the GLM 5.3 review clause: settled, it would either confirm self hosting as designed or force a substitute frontier model into the register. Each is a checkpoint, not a blocker: the design holds its shape either way, and the cost of settling each is a meeting, not a rebuild.

The Record Stays with the Fleet That Produced It

The object model, the weights, the decision record and the boundary all belong to the joint venture, so the intelligence compounds for the operation that generated it.

Chapter 9 showed how the design proves itself through counted phases and gates. This chapter states who owns what those phases build, because a live model of the structure phase is only worth building if the joint venture keeps it.

10.1  What the Joint Venture Owns

The object model is the JV's: the 15 objects, their typed links and their status vocabularies live in the JV's own instance, on JV servers in the site data room, and they outlive any single project system. The weights and fine tunes are the JV's: the RF-DETR checkpoints fine tuned on site footage, the Chronos-2 forecasts tuned on the yard's own pour history and the BGE-M3 embeddings over its own records all carry Apache 2.0 or MIT terms, so the operator holds them outright, and the GLM 5.3 bespoke license permits commercial use, fine tuning and redistribution for internal work. The decision record is the JV's: every re-sequencing recommendation, the person who approved or rejected it and the outcome that followed are kept as objects the next decision reads, a record whose preservation matters precisely because unmanaged data has cost other contractors dearly in litigation (Minerva26 2023). The boundary is the JV's: every stream, weight and decision stays inside the Kingdom on hardware the JV controls, and worker data is stewarded under the operator's own accountability, a duty regulators elsewhere have enforced with real penalties (YNA 2026).

10.2  The Offer Behind the Design

CodeNinja designed this system on Praxis, its platform for designing physical AI systems, and the design maps directly onto its offer: Adaptive Operations is the sensing, detection and forecasting of physical behavior, from edge cameras and crane logs to the three day slip forecast; Decision Systems is the ranking, attribution and re-sequencing that a named planner or crane coordinator approves; Hyper Ontology is the object model at the center of Chapter 5; Hyper Pragma is the agentic work surface where planners, the crane coordinator and HSE officers build their own daily agents; Hyper Engram is the kept record of decisions and outcomes that each re-sequencing recommendation reads before it is made; and Sovereign Infrastructure is the posture the JV chose, its own hardware, open-weight licenses and operation inside the Kingdom.

One Live Picture, Built From Records the Site Already Holds

Structure Phase Watch is a single live model of a construction structure phase: fifteen objects spanning cranes, units, trucks, permits, workers, zones and pours, fed by twelve systems through three adapter families, hardened at the edge for dust and heat, sized for sovereign operation on the operator's own servers, and arranged so that a forecast slip and a live breach both arrive as evidence a named planner, crane coordinator or HSE officer decides on.

The same shape runs wherever an operation keeps a schedule of record, a production register and a gate or flow log that no one has joined: swap the objects for that industry's assets, place detection where the connection is weakest, place reasoning in the jurisdiction that must hold the record, and keep every recommendation at the desk of a person whose name the record carries.

Every Choice Traces Back to a Recorded Reading

Produced on Praxis, the design keeps its reasoning on the record: the ask, the room, eight lenses and the patterns they surfaced, so any choice can be traced to what justified it.

Chapter 10 established that the record of decisions belongs to the joint venture. This chapter applies the same discipline to the design itself: produced on Praxis, every choice in this paper keeps its reasoning on the record, so a reader can trace any decision back to what justified it. Figure 9 shows that path from the ask to the equipment classes.

11.1  Contextualizing the Ask

Every design in the series is produced on Praxis, and this chapter is the audit trail. The ask, in the operator's words, was one live picture of the structure phase: precast production against the pour sequence, crane utilisation and lift plan compliance, truck flow through gates and laydown areas, and the people and equipment conflicts that cause both delay and injury, with warnings before a slip reaches the look ahead and breach detection while it happens. Praxis assigned the design to the physical operations family in heavy industry and construction. What was in the room and read in full, listed here and available on request: the operator's written requirement and its hypothesis about crane idle time and laydown exposure; the inventory of 12 named systems and their data; the object and link plan; the stack cards with their tooling and hardware readings; the model catalog entries; the risk register; and the phase plan with its gates. Nothing in this paper rests on a conversation that was not written down.

11.2  The Eight Lenses

Table 6 records what each lens could see, what it cited and what it contributed. Seven lenses returned readings; one returned nothing and is shown as a gap.

11.3  Patterns Adopted and Set Aside

The lenses surfaced patterns the design adopted and patterns it refused. Adopted: an adapter tier with provenance classes so every object carries its origin; file based schedule integration over an API whose consent was unconfirmed; open weights self hosted so the JV owns its own detections; shadow mode before any flag is acted on; Apache licensed tracking to avoid the copyleft exposure of the alternative collection. Set aside: packaged site safety vision products, because they rent the exact weights the sovereignty requirement obliges the JV to own; direct P6 API access as the baseline, for the consent reason above; a hardware data diode, because the whole estate sits inside one JV perimeter and the batch plant historian is mirrored read-only on the same network; and sovereign cloud migration, which the owner's policy permits but the engineer placed behind the JV's own servers as a later option.

11.4  Where the Reasoning Lands

The reasoning lands on four equipment classes and their sizing rules: the 141 GB HBM GPU class that holds the frontier weights of the work surface, 753 GB at FP8 with headroom for KV cache and activations inside one node; the fixed thermal camera class, specified at 9 Hz or less to stay outside the export license to Saudi Arabia; the enclosure thermal budget, sized for dust, solar gain and summer ambient with cleaning as a design parameter; and the reuse-or-not camera decision, settled by a six gate pixels-on-target survey per existing unit. Each class traces back through Table 6 to the lens that cited it and the room where it was read. That is the point of this chapter: everything shown in this paper was recorded reading, and nothing is inferred.