Phased Process Witnessing

1. The Problem: Phased Processes Run on Trust

Every car, aircraft, building, robot, and drug batch goes through sequential phases before it reaches the public. Foundation before framing. Crash testing before production. Sterilization before release. Each phase depends on the one before it.

Today, the evidence that Phase 1 was complete before Phase 2 began is a signature on a form. A checkbox in a spreadsheet. A PDF attached to an email. There is no cryptographic proof. No tamper-evident record. No way for a machine, an insurer, or a regulator to independently verify that the sequence was honored.

A $400 million building and a $4 million robot fleet rely on the same evidence format as a 1990s fax machine.

The gap is not the inspection itself. Inspectors are thorough. The gap is what happens to the evidence afterward: it sits in disconnected systems where it can be lost, altered, or presented out of sequence. When something goes wrong, the investigation is forensic archaeology through filing cabinets and email chains.

Phased Process Witnessing closes that gap. Every inspection, test result, and gate decision becomes a cryptographic leaf in a hierarchical Merkle tree. The tree is tamper-evident. The proofs are offline-verifiable. And the structure root is a single hash that a payment system, an insurance platform, or an autonomous agent can read in milliseconds.

2. Three-Tier Hierarchical Merkle Trees

The SWT3 protocol already uses Merkle trees for daily evidence rollups. A flat tree works when all attestations are equal. But phased processes have structure: individual attestations belong to milestones, milestones belong to phases, and phases belong to a project or production run. The evidence needs to reflect that hierarchy.

Phased Process Witnessing introduces a three-tier tree:

    Attestation Fingerprints
    +---------+ +---------+ +---------+
    | fp_1    | | fp_2    | | fp_3    |     Individual inspection results
    +----+----+ +----+----+ +----+----+
         |           |           |
         +-----+-----+     +----+
               v            v
        +-----------+ +-----------+
        |Milestone A| |Milestone B|         SWT3:MILESTONE_LEAF / NODE
        |   Root    | |   Root    |
        +-----+-----+ +-----+-----+
              |              |
              +------+-------+
                     v
             +--------------+
             |  Phase Root  |               SWT3:PHASE_LEAF / NODE
             | "Foundation" |
             +------+-------+
                    |
        +-----------+-----------+
        v           v           v
    Foundation   Framing    Finishes
      Phase       Phase      Phase
        |           |           |
        +-----------+-----------+
                    v
            +--------------+
            |  Structure   |                SWT3:STRUCTURE_LEAF / NODE
            |    Root      |
            |"Building Alpha"|
            +--------------+

Each tier uses its own pair of cryptographic prefixes. A milestone hash can never collide with a phase hash, and a phase hash can never collide with a structure hash. This is domain separation, the same principle that prevents cross-protocol attacks in TLS and that NIST formalizes in SP 800-185 for derived hash functions.

The structure root is a single hash that represents the complete cryptographic state of an entire project, fleet, or production line. Change one attestation at the bottom and the structure root changes. The math is the audit trail.

3. Seven Domains, One Engine

The three-tier pattern is domain-agnostic. The same engine that witnesses a building inspection witnesses a crash test, a drug batch release, or a grid connection. Only the labels change.

Same engine. Same proofs. Same verification. Different domain labels.

4. Walkthrough: Building Alpha

A general contractor is building a three-story commercial structure. The project has three phases: Foundation, Framing, and Finishes. Each phase has milestones with required inspections. No phase can begin until the previous phase's gate is open.

Step 1: Define the structure

The contractor creates a structure called "Building Alpha" with three phases. Each phase contains milestones, and each milestone lists the procedures that must pass before the milestone is complete.

• Foundation Phase: Structural inspection (CON-STR.1), insulation verification (CON-INS.1)
• Framing Phase: Environmental compliance (CON-ENV.1), safety inspection (CON-SAF.1)
• Finishes Phase: Final inspection (CON-FIN.1)

Step 2: Inspections happen, leaves accumulate

As each inspection completes, the result is recorded as an attestation leaf in the appropriate milestone. The milestone root recomputes automatically. The phase root recomputes. The structure root recomputes. Every new inspection changes the root hash, creating a tamper-evident history.

Step 3: Phase gate check

Before Framing can begin, the Foundation phase gate is evaluated. The gate checks every milestone in the phase:

    Milestone: Structural        Milestone: Insulation
    +------------------+         +------------------+
    | CON-STR.1  PASS  |         | CON-INS.1  FAIL  |
    | CON-STR.1  PASS  |         | CON-INS.1  PASS  |  <-- remediation
    +--------+---------+         +--------+---------+
             |                            |
             +------------+---------------+
                          v
                  +---------------+
                  |  GATE CHECK   |
                  |  All terminal |
                  |  verdicts PASS|
                  +-------+-------+
                          v
                     GATE_OPEN

The gate check itself is recorded as a witness leaf. GATE_OPEN or GATE_BLOCKED becomes part of the Merkle tree. The decision to advance is not just logged; it is cryptographically committed.

4.5 Visceral Walkthrough: The Insulation Failure

Tuesday morning. The building inspector arrives at Building Alpha for the insulation inspection (CON-INS.1). She opens the wall cavity in Section B and finds wet insulation -- the vapor barrier was installed backwards, trapping moisture against the sheathing. She marks the inspection as FAIL.

The FAIL leaf enters the tree

from swt3_ai.milestone_merkle import MilestoneAccumulator

acc = MilestoneAccumulator(structure_id="ST-building-alpha")
# ... phases and milestones already defined ...

# Inspector records the failure
acc.add_leaf("MS-structural", "f1a2b3c4d5e6",
    "CON-INS.1", verdict="FAIL", clearing_level=1)

# The milestone root changes immediately
# The Foundation phase root changes
# The structure root changes
# The failure is now part of the permanent record

The general contractor receives the FAIL notification. The team tears out the vapor barrier in Section B, reinstalls it correctly, and schedules a re-inspection for Thursday.

The remediation and re-inspection

Thursday. The inspector returns. The vapor barrier is now correctly installed. She marks the re-inspection as PASS.

# Thursday: re-inspection passes
acc.add_leaf("MS-structural", "a7b8c9d0e1f2",
    "CON-INS.1", verdict="PASS", clearing_level=1)

# Both leaves are in the tree: the FAIL and the PASS
# The terminal verdict for CON-INS.1 is now PASS
# (terminal = most recent chronological result)

The original FAIL leaf is never deleted. It remains in the milestone tree permanently. The terminal verdict logic evaluates the most recent result for each procedure. CON-INS.1 went FAIL, then PASS -- the procedure is resolved. But the full history is preserved. Six months from now, an auditor or claims investigator can see that the insulation was initially installed incorrectly, remediated, and re-inspected.

The gate check

# Check if Foundation phase is ready to advance
gate = acc.check_gate("PH-foundation")
print(gate["passed"])              # True
print(gate["failing_milestones"])  # []
print(gate["unresolved_fails"])    # []

# Both CON-STR.1 (structural) and CON-INS.1 (insulation)
# have terminal PASS verdicts. The gate opens.

The override scenario

Now consider a different timeline. The re-inspection is scheduled for Thursday, but the framing crew is arriving Monday and the GC is under schedule pressure. The project manager decides to advance past the Foundation gate with the insulation failure still unresolved.

# PM overrides the gate with an open insulation failure
from swt3_ai.milestone_merkle import MilestoneAccumulator

# The override is recorded with full accountability
# - WHO authorized it (hashed identity)
# - WHY (reason code)
# - WHAT was unresolved at the time
# The override leaf becomes a permanent part of the tree

The override leaf records the PM's identity hash, the reason, and the list of unresolved failures at the moment of override. It cannot be removed. When the insurer reviews the project six months later, the override is visible: framing began while the insulation was still failed. The PM made a deliberate choice under schedule pressure, and the choice is cryptographically recorded.

5. Phase Gates: Nothing Moves Until the Math Says So

A phase gate evaluates whether all milestones in a phase satisfy their requirements. The check is deterministic: every required procedure must have a terminal PASS verdict. If any procedure is missing or has an unresolved FAIL, the gate blocks.

Configurable thresholds

Some milestones require more than one attestation. A structural inspection milestone might require three independent inspections before it is considered satisfied. The minimum attestation count is configurable per milestone.

Emergency overrides

In practice, overrides happen. A project manager may need to advance past a gate with known open items. The protocol records this with full accountability:

• The identity of the person who authorized the override (stored as a hash, not in plaintext)
• The reason code for the override
• The list of unresolved failures at the time of override
• The milestone root at the moment the override was issued

The override itself becomes a leaf in the tree. It cannot be removed or hidden. Months later, an auditor or claims investigator can see exactly what was bypassed, by whom, and what the state of evidence was at that moment.

6. Rollups: From One Building to an Entire Community

A single structure root represents one project: one building, one vehicle, one production batch. But most real-world scenarios involve portfolios.

• Home communities: A developer builds 200 homes. Each home has its own structure root. The developer presents one portfolio root to the insurer covering all 200.
• Vehicle fleets: An OEM validates 10,000 autonomous vehicles. Each vehicle has a structure root from its validation pipeline. The OEM presents one fleet root to the type approval authority.
• Production lines: A pharma manufacturer produces 50 batches per day. Each batch has a structure root. QA signs off on the daily rollup.

The insurer, the regulator, and the OEM all verify the same root. They ask different questions, but the cryptographic proof is the same. One hash. Tamper-evident. Offline-verifiable.

7. Machine-Readable Accountability

The structure root is a hash. Machines read hashes. This is not a dashboard designed for a person to click through. It is a protocol that machines and AI systems can process in milliseconds and act on immediately.

Payment release

An escrow system holds $2 million for a construction phase. When the phase gate returns GATE_OPEN with a verified multi-tier proof, the funds release automatically. The escrow platform does not review inspection reports. It verifies a hash.

Insurance claims

After a structural defect, the claims adjuster queries the structure. The full phase history is visible: which inspections passed, which failed and were remediated, whether any gates were overridden, and who authorized the overrides. The investigation that once took six months takes six seconds.

Claims walkthrough: four API calls

A water intrusion defect is reported in Building Alpha 18 months after completion. The insurer's claims platform traces the evidence in four steps:

1. Get the structure root -- GET /api/v1/merkle/milestone?structure_id=ST-building-alpha returns the full structure with all phases and milestones.
2. Check the Foundation gate -- GET /api/v1/merkle/milestone/gate?phase_id=PH-foundation shows the gate status. Was it GATE_OPEN or overridden? If overridden, which procedures were unresolved?
3. Pull the insulation milestone -- Filter the milestone leaves for CON-INS.1. The claims platform sees: FAIL on Tuesday (wet insulation), PASS on Thursday (re-inspection after remediation). The defect was found and fixed during construction.
4. Generate a proof -- GET /api/v1/merkle/milestone/proof?fingerprint=f1a2b3c4d5e6&structure_id=ST-building-alpha returns the multi-tier proof linking the specific insulation failure to the structure root. The proof is self-contained and offline-verifiable.

The claims platform now knows: the insulation was initially installed incorrectly, was caught by inspection, was remediated, and passed re-inspection. The water intrusion is not related to the original defect (different location). The claim proceeds on its merits, with the construction quality evidence available in seconds rather than months of document archaeology.

AI and autonomous systems

An autonomous vehicle's OTA update system checks its own phase gate before rolling firmware to the next batch. A robotic fleet management platform verifies that all units in a deployment group have PASS status before enabling a new operational mode. The phase gate is the authorization mechanism, and no human is in the loop for the verification step.

Regulatory reporting

A type approval authority receives a fleet root covering 10,000 vehicles. Rather than auditing each vehicle individually, the authority verifies the root hash and spot-checks individual structure roots using multi-tier proofs. Full coverage. Logarithmic effort.

8. Remediation and Evidence History

When an inspection fails, the failure is not deleted. It becomes a leaf in the milestone tree with a FAIL verdict. When the issue is remediated and the inspection is repeated, the new PASS result is added as another leaf. Both remain in the tree permanently.

The protocol evaluates the terminal verdict: the most recent result for each procedure. A procedure that went FAIL, then PASS, is considered resolved. But the full history is preserved. An auditor can see every attempt.

9. Scope Amendments

Requirements change during a project. A new environmental regulation takes effect. A change order adds procedures. A scope reduction removes others. In traditional systems, these changes are documented in meeting minutes or change order forms that may or may not be attached to the right phase.

In the phased process tree, every scope amendment is a witnessed leaf. The amendment records which procedures were added, which were removed, who authorized the change, and when. The milestone's effective requirements are computed by applying all amendments in sequence.

10. Sensor Integration

Physical processes produce sensor data: temperature, humidity, structural load, force limits, vibration, pressure, flow rate. In traditional systems, sensor readings are logged separately from compliance records. The inspection report says "passed." The sensor data sits in a different database.

Phased Process Witnessing hashes sensor data directly into the attestation fingerprint. The reading is not referenced. It is cryptographically bound. If the sensor data changes after the fact, the fingerprint no longer matches. The attestation becomes invalid.

This means the sensor reading IS the evidence factor. Not a report about the sensor reading. Not a summary. The actual measurement, hashed at the moment of capture, is part of the cryptographic proof.

For example, a concrete pour on a construction site has temperature and humidity sensors embedded in the formwork. The readings at the time of inspection (22.4°C ambient, 47% relative humidity, 28-day compressive strength of 4,200 PSI) are hashed into the attestation fingerprint. If anyone later claims the pour happened at a different temperature, the hash will not match. The sensor data and the compliance attestation are mathematically locked together.

For IoT-enabled construction sites, automated production lines, and robotic systems with continuous monitoring, this creates a bridge between operational data and compliance evidence. The two become inseparable.

11. Cross-Phase Consistency

Phases in a structure must be internally consistent. The protocol enforces three rules automatically:

• Clearing level monotonicity: The security classification cannot decrease between phases. If Phase 1 operates at clearing level 2 (Sensitive), Phase 2 cannot drop to level 1 (Standard). This prevents evidence downgrading.
• Framework consistency: If a structure is being built under a specific regulatory framework, all phases must reference the same framework. A mid-project switch from one framework to another is flagged.
• Process version consistency: If the process definition changes between phases, the inconsistency is detected and recorded.

When a consistency violation is detected, the protocol automatically mints a FAIL attestation leaf recording the specific violation. This is not a warning. It is a witnessed event in the Merkle tree, visible to any verifier.

12. Quick Start

Python

from swt3_ai.milestone_merkle import MilestoneAccumulator

acc = MilestoneAccumulator(structure_id="ST-building-alpha")

# Define phases
acc.add_phase("PH-foundation", "Foundation", sequence=0)
acc.add_phase("PH-framing", "Framing", sequence=1)
acc.add_phase("PH-finishes", "Finishes", sequence=2)

# Define milestones with required procedures
acc.add_milestone("MS-structural", "PH-foundation", "Structural",
                  required_procedures=["CON-STR.1", "CON-INS.1"])
acc.add_milestone("MS-framing", "PH-framing", "Framing",
                  required_procedures=["CON-ENV.1", "CON-SAF.1"])

# Record inspection results
acc.add_leaf("MS-structural", "a1b2c3d4e5f6", "CON-STR.1", verdict="PASS")
acc.add_leaf("MS-structural", "f6e5d4c3b2a1", "CON-INS.1", verdict="PASS")

# Check the phase gate
result = acc.check_gate("PH-foundation")
print(result["passed"])       # True
print(acc.structure_root)     # Single hash: entire project state

# Generate and verify a proof for any attestation
proof = acc.get_multi_tier_proof("a1b2c3d4e5f6")

# Anyone can verify offline, with no access to the full tree
from swt3_ai.milestone_merkle import verify_multi_tier_proof
assert verify_multi_tier_proof("a1b2c3d4e5f6", proof)

TypeScript

import { MilestoneAccumulator, verifyMultiTierProof } from "@tenova/swt3-ai/milestone-merkle";

const acc = new MilestoneAccumulator("ST-building-alpha");

acc.addPhase("PH-foundation", "Foundation", 0);
acc.addPhase("PH-framing", "Framing", 1);

acc.addMilestone("MS-structural", "PH-foundation", "Structural",
  ["CON-STR.1", "CON-INS.1"]);

acc.addLeaf("MS-structural", "a1b2c3d4e5f6", "CON-STR.1", "PASS");
acc.addLeaf("MS-structural", "f6e5d4c3b2a1", "CON-INS.1", "PASS");

const gate = acc.checkGate("PH-foundation");
console.log(gate.passed);          // true
console.log(acc.structureRoot);     // Single hash

const proof = acc.getMultiTierProof("a1b2c3d4e5f6");

// Anyone can verify offline
console.log(verifyMultiTierProof("a1b2c3d4e5f6", proof!)); // true

API

All endpoints require Bearer authentication (axm_* API key or session token).

Creating a structure (POST)

POST /api/v1/merkle/milestone
Content-Type: application/json
Authorization: Bearer axm_live_...

{
  "action": "create",
  "name": "Building Alpha",
  "domain": "construction",
  "phases": [
    {
      "name": "Foundation",
      "milestones": [
        {"name": "Structural", "required_procedures": ["CON-STR.1", "CON-INS.1"]}
      ]
    },
    {
      "name": "Framing",
      "milestones": [
        {"name": "Environmental", "required_procedures": ["CON-ENV.1", "CON-SAF.1"]}
      ]
    }
  ]
}

Response: { "ok": true, "structure_id": "ST-...", "phase_ids": ["PH-..."], "milestone_count": 2 }

Recording an attestation (POST)

POST /api/v1/merkle/milestone
Content-Type: application/json
Authorization: Bearer axm_live_...

{
  "action": "add_leaf",
  "milestone_id": "MS-...",
  "fingerprint": "a1b2c3d4e5f6",
  "procedure_id": "CON-STR.1",
  "verdict": "PASS"
}

Response: { "ok": true, "milestone_root": "...", "leaf_count": 1 }

Checking a gate (GET)

GET /api/v1/merkle/milestone/gate?phase_id=PH-...

Response: {
  "ok": true,
  "passed": true,
  "gate_status": "GATE_OPEN",
  "gate_fingerprint": "...",
  "failing_milestones": [],
  "unresolved_fails": [],
  "missing_procedures": []
}

Full SDK documentation: sovereign.tenova.io/docs

13. References

• SWT3 SDK Documentation (Python, TypeScript, and 5 additional languages)
• EU Machinery Regulation Crosswalk
• ISO 10218:2025 Robot Safety Crosswalk
• ISO 42001 Implementation Evidence Guide
• EU Battery Regulation DPP: End-to-End Lifecycle Witnessing
• Construction Phase-Gate Witnessing
• Energy Demand Response Lifecycle
• Multi-Agent Workflow Phased Witnessing
• Construction AI Compliance Witnessing
• Physical AI Governance: Liability Boundaries in Manufacturing
• SWT3 Anchor Verification (public, offline-capable)
• NIST SP 800-185: SHA-3 Derived Functions (domain separation principles)
• ISO 26262: Functional Safety for Road Vehicles
• DO-178C: Software Considerations in Airborne Systems and Equipment Certification
• RTCA DO-254: Design Assurance for Airborne Electronic Hardware
• 21 CFR Part 211: Current Good Manufacturing Practice for Finished Pharmaceuticals
• EU GMP Annex 11: Computerised Systems