A $12M commercial office build, six phases, five CON procedures. Every inspection witnessed. Every gate cryptographically locked. Every draw request backed by proof.
v8.1 Preview • Hierarchical Milestone Merkle Trees ship in SWT3 v8.1 (November 2026). SDK parity across Python and TypeScript. API endpoints go live on release.
Who this is for: General contractors, construction project managers, building inspectors, construction lenders, surety bond underwriters, insurance adjusters, AIA contract administrators, and developers integrating phase-gate governance into construction management platforms.
The project is a three-story commercial office building in a mid-Atlantic metro area. $12M total contract value. 14-month construction timeline. Steel frame with curtain wall, Type I-B construction per IBC. The owner is a regional development firm. The bank holds a construction loan with six scheduled draw releases tied to phase completion.
| Role | Party | Interest |
|---|---|---|
| General Contractor (GC) | Prime contractor | Sequence compliance, payment collection, liability protection |
| Owner | Regional development firm | Budget control, schedule adherence, certificate of occupancy |
| Building Inspector | Jurisdiction AHJ | Code compliance per IBC/IRC, life safety sign-off |
| Construction Lender | Regional bank | Draw release tied to verified phase completion |
| Insurer | Builder's risk carrier | Process integrity evidence for underwriting and claims |
| Bonding Company | Surety provider | Performance bond verification, subcontractor default exposure |
Today, the evidence chain connecting an inspection to a draw release is a stack of paper: inspection reports, lien waivers, architect certifications, and AIA G702/G703 pay applications. Each document lives in a different system. None are cryptographically linked. When a dispute arises -- and on a $12M project, disputes arise -- the forensic investigation is manual, slow, and expensive.
SWT3 phase-gate witnessing creates a single tamper-evident structure that links every inspection, every sensor reading, every gate decision, and every payment release into one verifiable Merkle tree. The bank, the insurer, and the bonding company all verify the same root hash. Different questions, same proof.
The project follows six construction phases, each with milestones representing required inspections. No phase can begin until the previous phase's gate is open. The GC defines the structure at project kickoff and it becomes the cryptographic backbone of the build.
| Phase | Seq | Key Milestones | Required Inspections |
|---|---|---|---|
| 1. Site Preparation | 0 | Erosion control, utility locate, grading | Grading permit sign-off, erosion control inspection, utility clearance |
| 2. Foundation | 1 | Excavation, footings, foundation walls, waterproofing | Footing inspection, foundation wall inspection, waterproofing verification, drainage test |
| 3. Structure | 2 | Steel erection, concrete decks, framing | Structural steel inspection, concrete placement inspection, load test, fireproofing inspection |
| 4. MEP (Mechanical, Electrical, Plumbing) | 3 | Rough-in, fire suppression, HVAC, electrical | Rough plumbing inspection, electrical rough-in, fire suppression test, HVAC duct inspection |
| 5. Finishes | 4 | Drywall, flooring, exterior envelope, elevator | Insulation inspection, fire-rated assembly inspection, elevator inspection, envelope leak test |
| 6. Commissioning | 5 | Systems testing, punch list, final inspection | Mechanical commissioning, electrical commissioning, fire alarm acceptance test, final building inspection |
Each milestone collects attestation leaves as inspections complete. The milestone root recomputes with every new leaf. The phase root recomputes. The structure root recomputes. One inspection result at the bottom changes the root hash at the top. The math is the audit trail.
Structure Root: "Meridian-Office-3S"
|
+-- Phase 0: Site Preparation [GATE_OPEN]
| +-- MS: Erosion Control (CON-ENV.1 PASS)
| +-- MS: Grading (CON-INS.1 PASS)
|
+-- Phase 1: Foundation [GATE_OPEN]
| +-- MS: Footings (CON-STR.1 PASS, CON-INS.1 PASS)
| +-- MS: Waterproofing (CON-ENV.1 PASS)
| +-- MS: Drainage (CON-ENV.1 FAIL -> PASS)
|
+-- Phase 2: Structure [GATE_BLOCKED]
| +-- MS: Steel Erection (CON-STR.1 PASS, CON-SAF.1 PASS)
| +-- MS: Concrete Decks (CON-STR.1 ... pending)
|
+-- Phase 3: MEP [locked - awaiting Phase 2]
+-- Phase 4: Finishes [locked - awaiting Phase 3]
+-- Phase 5: Commissioning [locked - awaiting Phase 4]Project state mid-build: Foundation complete, Structure phase in progress with one milestone pending.
The CON namespace contains five procedures purpose-built for construction witnessing. Each procedure maps to a category of inspection or attestation that the SWT3 protocol collects evidence from and records as a Merkle leaf.
Records evidence from structural inspections: steel connections, concrete placement, load tests, fireproofing. Factor A captures the inspection type. Factor B captures the measured value or test result. Factor C captures the inspector credential or license number hash.
Records evidence from general building inspections: footing inspections, rough-in inspections, insulation verification, fire-rated assembly checks. The general-purpose inspection procedure for any AHJ sign-off that does not fall under a specialized category.
Records evidence from environmental compliance checks: erosion control, stormwater management, drainage tests, waterproofing verification, air quality monitoring during demolition or abatement.
Records evidence from safety inspections: fall protection, scaffolding, crane operation, confined space, trenching and excavation. Maps directly to OSHA 1926 subparts.
Records evidence from payment-related events: draw request submission, architect certification, lien waiver collection, retainage release. Links financial milestones to the inspection evidence that authorized them.
| Phase | Milestone | Procedure | What the Inspection Checks |
|---|---|---|---|
| Site Prep | Erosion control | CON-ENV.1 | Silt fence, inlet protection, stabilized entrance per SWPPP |
| Grading | CON-INS.1 | Grades, elevations, compaction test results per civil drawings | |
| Foundation | Footings | CON-STR.1, CON-INS.1 | Rebar placement, bearing capacity, dimensional compliance |
| Waterproofing | CON-ENV.1 | Below-grade membrane continuity, drainage board placement | |
| Drainage | CON-ENV.1 | Perimeter drain flow test, sump pit function, backfill spec | |
| Structure | Steel erection | CON-STR.1, CON-SAF.1 | Connection bolt torque, plumb and level, fall protection compliance |
| Concrete decks | CON-STR.1 | Concrete placement, cylinder breaks, cure temperature monitoring | |
| MEP | Rough-in | CON-INS.1 | Plumbing pressure test, electrical rough-in, duct integrity |
| Fire suppression | CON-SAF.1, CON-INS.1 | Hydrostatic test, alarm device placement, flow switch operation | |
| Finishes | Insulation | CON-INS.1, CON-ENV.1 | R-value verification, vapor barrier continuity, energy code compliance |
| Envelope | CON-STR.1 | Curtain wall leak test, window flash inspection, air barrier continuity | |
| Commissioning | Systems testing | CON-INS.1, CON-SAF.1 | Mechanical balance, electrical panel schedule, fire alarm acceptance |
| Final inspection | CON-FIN.1, CON-INS.1 | Certificate of occupancy, punch list completion, final pay application |
The building inspector's sign-off is the gate check. When the inspector approves a phase, the GC calls check_gate() on that phase. The protocol evaluates deterministically: every milestone in the phase must have a terminal PASS verdict for each required procedure. If any procedure has an unresolved FAIL or is missing entirely, the gate blocks.
During the Foundation phase, the drainage test fails. Water is pooling at the northwest corner instead of flowing to the sump. The inspector records a FAIL. The GC's drainage subcontractor re-grades the perimeter, adds additional drain tile, and requests re-inspection.
Milestone: Drainage (Phase 1 - Foundation)
+-----------------------------------------------+
| Leaf 1: CON-ENV.1 FAIL (2027-02-14 09:30) | drainage test failed
| Leaf 2: CON-ENV.1 PASS (2027-02-21 14:15) | re-inspection after fix
+-----------------------------------------------+
|
Gate Check: Phase 1 "Foundation"
+-----------------------------------------------+
| MS Footings: CON-STR.1 PASS, INS.1 PASS|
| MS Waterproofing: CON-ENV.1 PASS |
| MS Drainage: CON-ENV.1 PASS (terminal) |
+--------------------+--------------------------+
|
GATE_OPEN
|
Phase 2 "Structure" UNLOCKEDThe drainage FAIL is permanently recorded. The remediation PASS is the terminal verdict. The gate opens because all terminal verdicts are PASS.
The GATE_OPEN decision itself becomes a leaf in the Merkle tree. The timestamp, the phase root at the moment of evaluation, and the list of evaluated milestones are all cryptographically committed. This leaf is permanent evidence that the Foundation phase was complete before Structure began.
Assessor Note -- Phase Gate Timestamp Ordering
The GATE_OPEN leaf must precede the first attestation in the next phase. Verify that the GATE_OPEN timestamp for Phase N is earlier than the earliest attestation timestamp in Phase N+1. If the ordering is violated, the sequence integrity is compromised. This is the first check in any phase-gate audit.
Three weeks behind schedule, the project manager considers advancing to the Structure phase before the drainage re-inspection is complete. If the PM overrides the gate, the protocol records it with full accountability: the PM's identity hash, the reason code, the list of unresolved FAIL verdicts, and the milestone root at the moment of override.
Assessor Note -- Override Accountability
If a PM overrides a gate under schedule pressure, the override leaf is permanent evidence in the Merkle tree. It cannot be removed, altered, or hidden. During a dispute, a claims investigation, or a code enforcement review, the override is immediately visible: who authorized it, why, and what failures were unresolved at that moment. A gate that was overridden is not the same as a gate that passed cleanly. Both are distinguishable in the tree.
During construction, the Authority Having Jurisdiction (AHJ) may require additional inspections not in the original scope -- a geotechnical review after unexpected soil conditions, a fire marshal inspection after a change order adds a commercial kitchen, or a third-party structural peer review after a design modification. These AHJ mandates must update the milestone tree.
SWT3 handles this through scope amendments. A scope amendment leaf records which procedures were added (or removed), who authorized the change, and when. The milestone's effective requirements are recomputed by applying all amendments in sequence. The amendment itself is a witnessed leaf in the tree -- it cannot be silently added or removed.
For example, if the fire marshal requires an additional CON-SAF.1 inspection for the commercial kitchen hood suppression system, the GC adds a scope amendment to the MEP milestone. The gate will not open until both the original CON-SAF.1 (fire exit path) and the new CON-SAF.1 (kitchen suppression) have terminal PASS verdicts. The amendment leaf shows exactly when the requirement was added and who authorized it.
Assessor Note
Check for scope amendments in each milestone. An amendment that removes a required procedure is more significant than one that adds a procedure. If a CON-STR.1 structural inspection was originally required and later removed via amendment, verify the justification. A structural requirement removed after a schedule delay looks different from one removed after a design change eliminated the relevant structural element.
Physical construction produces sensor data that traditional inspection reports reference but do not cryptographically bind. SWT3 phase-gate witnessing hashes sensor readings directly into attestation fingerprints. The measurement IS the evidence -- not a summary of the measurement.
The third-floor concrete deck pour uses embedded temperature and humidity sensors in the formwork. The sensors record ambient temperature, internal concrete temperature, and relative humidity every 15 minutes during the cure period. Concrete monitoring produces two distinct attestations: one at placement (day-of conditions and field tests) and one at 28 days (cylinder break results from the testing lab).
Example sensor payload for a concrete placement inspection (day of pour):
# Sensor data captured at placement -- day-of field conditions
placement_data = {
"ambient_temp_c": 22.4,
"concrete_temp_c": 31.2,
"relative_humidity_pct": 47,
"slump_inches": 4.5,
"air_content_pct": 6.0,
"batch_ticket_number": "BT-2027-3841",
"sensor_ids": ["TC-3F-01", "TC-3F-02", "RH-3F-01"],
"capture_utc": "2027-05-18T14:30:00Z"
}
# Hash the sensor data into the attestation
import hashlib, json
sensor_hash = hashlib.sha256(
json.dumps(placement_data, sort_keys=True).encode()
).hexdigest()[:12]
# Placement attestation -- CON-STR.1 with day-of conditions
acc.add_leaf(
"MS-concrete-3F",
fingerprint, # computed by the witness pipeline
"CON-STR.1",
verdict="PASS"
)
# factor_b in the witness payload: sensor_hash
# factor_c in the witness payload: inspector license hashTwenty-eight days later, the lab breaks the test cylinders and reports compressive strength. This result is recorded as a second CON-STR.1 attestation in the same milestone, linking the lab results to the original placement conditions:
# 28-day cylinder break results from testing lab
lab_results = {
"batch_ticket_number": "BT-2027-3841", # links to placement
"28day_compressive_psi": 4200,
"specified_strength_psi": 4000,
"test_lab": "Atlas Testing LLC",
"cylinder_ids": ["CYL-3F-A", "CYL-3F-B", "CYL-3F-C"],
"break_date_utc": "2027-06-15T10:00:00Z"
}
lab_hash = hashlib.sha256(
json.dumps(lab_results, sort_keys=True).encode()
).hexdigest()[:12]
# Second attestation in same milestone -- 28-day results
acc.add_leaf(
"MS-concrete-3F",
lab_fingerprint,
"CON-STR.1",
verdict="PASS" # 4200 PSI > 4000 PSI specified
)Both attestations live in the same milestone. The placement conditions (temperature, slump, air content) and the 28-day break results (compressive strength) are cryptographically linked through the milestone root. If anyone later claims the pour happened at a different temperature or that the lab results were falsified, the hash chain reveals the discrepancy. The batch ticket number connects the two attestations by reference, and both are independently verifiable.
During steel erection, the structural engineer performs connection bolt torque verification on a sample of moment connections. The torque wrench readings, bolt lot numbers, and connection identifiers are hashed and embedded in the CON-STR.1 factors. The structure does not store the raw readings -- only their hash. The raw data stays with the GC's project files. Any verifier who has access to the raw data can recompute the hash and confirm the binding.
Assessor Note -- Sensor Hash Verification
When evaluating sensor-integrated attestations, request both the raw sensor data and the attestation record from the contractor. Recompute the fingerprint from the raw data. If the recomputed hash matches the attestation's factor, the binding is verified and the sensor data has not been altered since capture. If it does not match, the data has been modified after the attestation was minted.
On a $12M construction loan, draw releases are tied to phase completion. The traditional process: the GC submits an AIA G702/G703 pay application, the architect certifies the work, the bank's inspector visits the site, and the lender releases funds. This takes 2-4 weeks per draw and involves manual document review at every step.
With phase-gate witnessing, the draw release process becomes verifiable in seconds.
GC completes Phase 2 (Structure)
|
Building inspector signs off
|
GC calls: acc.check_gate("PH-structure")
|
Protocol returns: GATE_OPEN
+ structure_root + multi-tier proof
|
GC submits draw request with:
- AIA G702 pay application
- structure_root hash
- phase gate proof
|
Bank verifies the proof:
verify_multi_tier_proof(gate_fingerprint, proof)
|
Proof valid? --> Release Draw #3 ($2.1M)
|
CON-FIN.1 leaf minted: payment attestation
with draw amount, bank reference, timestampThe bank verifies a cryptographic proof instead of reviewing inspection reports. The payment attestation links the financial event to the inspection evidence.
The bank does not need access to the full Merkle tree. It receives a multi-tier proof -- a compact set of hashes that connects the gate decision to the structure root. Verification is a single computation. If the proof is valid, the bank has cryptographic evidence that all required inspections in the phase passed before the draw was requested.
The phase gate proof is one input to the draw release decision, not the sole trigger. In commercial construction lending, a draw release typically requires all of the following:
SWT3 accelerates the inspection verification step and creates an auditable link between the inspection evidence and the financial event. It does not replace the lien waiver collection, title update, or architect certification. The value is in turning the inspection review from a multi-week manual document chase into a single proof verification -- while the other prerequisites proceed in parallel.
The lender's platform receives the GC's draw request with the structure root and gate proof. The bank verifies the proof independently -- no access to the full tree required:
# Bank's lending platform verifies the GC's draw request
from swt3_ai.milestone_merkle import verify_multi_tier_proof
# GC submitted these with the AIA G702
gate_fingerprint = "g7h8i9j0k1l2" # from the GC's draw package
proof = { ... } # multi-tier proof from GC
# Bank verifies: does this gate proof resolve to a valid structure?
verified = verify_multi_tier_proof(gate_fingerprint, proof)
if verified:
print("Phase gate proof valid -- inspection evidence confirmed")
print(f"Structure root: {proof['structure_root']}")
# Proceed with other draw prerequisites (lien waivers, title, etc.)
else:
print("Phase gate proof INVALID -- do not release draw")
# Flag for manual review by bank inspectorThe verification is a single computation. If the proof is valid, the bank has cryptographic evidence that all required inspections in the phase passed before the draw was requested. The bank does not need to read inspection reports, contact the building inspector, or visit the site to verify the inspection status (though the bank's own inspector visit remains a separate prerequisite per the loan covenant).
The CON-FIN.1 leaf minted after payment creates a permanent link between the financial event and the inspection evidence that authorized it. Months later, during a lien dispute or a loan audit, the connection is immediate and verifiable. The lien waiver status, retainage amount, and draw number are recorded in the CON-FIN.1 attestation factors.
Assessor Note -- Payment Release Evidence Chain
Verify that the bank checked the gate proof BEFORE releasing funds. The CON-FIN.1 payment attestation leaf should have a timestamp that is later than the GATE_OPEN leaf for the corresponding phase. If the payment leaf precedes the gate leaf, the draw was released before the phase was verified -- a red flag in any loan audit or lien dispute.
A builder's risk policy covers the structure during construction. The insurer's underwriting decision traditionally relies on the GC's reputation, the project plans, and a site visit. With phase-gate witnessing, the insurer has access to the structure root -- a single hash that represents the complete state of process integrity across all phases.
At policy inception, the structure root covering the project definition (phases, milestones, required procedures) provides evidence that the GC has committed to a defined inspection sequence. During the policy term, the evolving structure root shows real-time process compliance. At renewal, the full phase history demonstrates whether gates were honored or overridden.
For Underwriters
The structure root covering all phases is evidence of process integrity at policy inception. A project with a fully defined phase-gate structure and zero overrides during the first two phases presents a different risk profile than a project with undefined milestones or multiple gate overrides. The root hash does not replace underwriting judgment -- it provides cryptographic evidence to inform it.
Eighteen months after occupancy, a water infiltration issue is traced to the third-floor curtain wall. The insurer needs to determine whether the installation was properly inspected. With phase-gate witnessing, the full history is immediately available:
Every answer is in the Merkle tree. The investigation that once took months of document discovery takes minutes of proof verification.
For Claims Adjusters
After a structural defect, the full phase history shows which inspections passed, which were remediated, and whether any gates were overridden. Expand the specific phase's Merkle branch to see every attestation leaf, including FAIL-then-PASS remediation sequences. Override leaves with their unresolved failure lists are particularly relevant -- they show exactly where process shortcuts occurred, if any.
The bonding company guarantees the GC's performance. If the GC defaults mid-project, the surety needs to understand exactly where the project stands: which phases are complete, which milestones are satisfied, and what work remains. The structure root and multi-tier proofs provide this instantly.
# Surety verifies project state after GC default
proof = acc.get_multi_tier_proof(last_known_fingerprint)
# Verify the proof against the published structure root
is_valid = verify_multi_tier_proof(last_known_fingerprint, proof)
# Check each phase gate
for phase_id in ["PH-site-prep", "PH-foundation", "PH-structure",
"PH-mep", "PH-finishes", "PH-commissioning"]:
result = acc.check_gate(phase_id)
print(f"{phase_id}: {'OPEN' if result['passed'] else 'BLOCKED'}")
if not result["passed"]:
print(f" Missing: {result['missing']}")
print(f" Failed: {result['failed']}")The surety knows immediately which phases are verified, which are partially complete, and which have unresolved failures. The completion bond payout can be scoped to exactly the remaining work.
from swt3_ai.milestone_merkle import MilestoneAccumulator, verify_multi_tier_proof
# Create the project structure
acc = MilestoneAccumulator(structure_id="ST-meridian-office-3S")
# Define six construction phases
acc.add_phase("PH-site-prep", "Site Preparation", sequence=0)
acc.add_phase("PH-foundation", "Foundation", sequence=1)
acc.add_phase("PH-structure", "Structure", sequence=2)
acc.add_phase("PH-mep", "MEP", sequence=3)
acc.add_phase("PH-finishes", "Finishes", sequence=4)
acc.add_phase("PH-commissioning", "Commissioning", sequence=5)
# Define milestones with required CON procedures
acc.add_milestone("MS-erosion", "PH-site-prep", "Erosion Control",
required_procedures=["CON-ENV.1"])
acc.add_milestone("MS-grading", "PH-site-prep", "Grading",
required_procedures=["CON-INS.1"])
acc.add_milestone("MS-footings", "PH-foundation", "Footings",
required_procedures=["CON-STR.1", "CON-INS.1"])
acc.add_milestone("MS-waterproof", "PH-foundation", "Waterproofing",
required_procedures=["CON-ENV.1"])
acc.add_milestone("MS-drainage", "PH-foundation", "Drainage",
required_procedures=["CON-ENV.1"])
acc.add_milestone("MS-steel", "PH-structure", "Steel Erection",
required_procedures=["CON-STR.1", "CON-SAF.1"])
acc.add_milestone("MS-concrete", "PH-structure", "Concrete Decks",
required_procedures=["CON-STR.1"])
acc.add_milestone("MS-roughin", "PH-mep", "Rough-In",
required_procedures=["CON-INS.1"])
acc.add_milestone("MS-firesup", "PH-mep", "Fire Suppression",
required_procedures=["CON-SAF.1", "CON-INS.1"])
acc.add_milestone("MS-insulation", "PH-finishes", "Insulation",
required_procedures=["CON-INS.1", "CON-ENV.1"])
acc.add_milestone("MS-envelope", "PH-finishes", "Envelope",
required_procedures=["CON-STR.1"])
acc.add_milestone("MS-systems", "PH-commissioning", "Systems Testing",
required_procedures=["CON-INS.1", "CON-SAF.1"])
acc.add_milestone("MS-final", "PH-commissioning", "Final Inspection",
required_procedures=["CON-FIN.1", "CON-INS.1"])
# Record inspection results as they happen
acc.add_leaf("MS-erosion", "a1b2c3d4e5f6", "CON-ENV.1", verdict="PASS")
acc.add_leaf("MS-grading", "b2c3d4e5f6a1", "CON-INS.1", verdict="PASS")
# Check Phase 0 gate
gate = acc.check_gate("PH-site-prep")
print(gate["passed"]) # True -- Site Prep complete
# Foundation inspections
acc.add_leaf("MS-footings", "c3d4e5f6a1b2", "CON-STR.1", verdict="PASS")
acc.add_leaf("MS-footings", "d4e5f6a1b2c3", "CON-INS.1", verdict="PASS")
acc.add_leaf("MS-waterproof", "e5f6a1b2c3d4", "CON-ENV.1", verdict="PASS")
# Drainage fails, then passes after remediation
acc.add_leaf("MS-drainage", "f6a1b2c3d4e5", "CON-ENV.1", verdict="FAIL")
acc.add_leaf("MS-drainage", "a2b3c4d5e6f7", "CON-ENV.1", verdict="PASS")
# Check Foundation gate
gate = acc.check_gate("PH-foundation")
print(gate["passed"]) # True -- terminal verdict is PASS
# The structure root reflects the entire project state
print(acc.structure_root) # Single hash: all phases, all milestones
# Generate a proof for any attestation
proof = acc.get_multi_tier_proof("c3d4e5f6a1b2")
# Anyone can verify offline
assert verify_multi_tier_proof("c3d4e5f6a1b2", proof)import { MilestoneAccumulator, verifyMultiTierProof } from "@tenova/swt3-ai/milestone-merkle";
const acc = new MilestoneAccumulator("ST-meridian-office-3S");
// Define six construction phases
acc.addPhase("PH-site-prep", "Site Preparation", 0);
acc.addPhase("PH-foundation", "Foundation", 1);
acc.addPhase("PH-structure", "Structure", 2);
acc.addPhase("PH-mep", "MEP", 3);
acc.addPhase("PH-finishes", "Finishes", 4);
acc.addPhase("PH-commissioning", "Commissioning", 5);
// Define milestones with required CON procedures
acc.addMilestone("MS-erosion", "PH-site-prep", "Erosion Control",
["CON-ENV.1"]);
acc.addMilestone("MS-grading", "PH-site-prep", "Grading",
["CON-INS.1"]);
acc.addMilestone("MS-footings", "PH-foundation", "Footings",
["CON-STR.1", "CON-INS.1"]);
acc.addMilestone("MS-waterproof", "PH-foundation", "Waterproofing",
["CON-ENV.1"]);
acc.addMilestone("MS-drainage", "PH-foundation", "Drainage",
["CON-ENV.1"]);
acc.addMilestone("MS-steel", "PH-structure", "Steel Erection",
["CON-STR.1", "CON-SAF.1"]);
acc.addMilestone("MS-concrete", "PH-structure", "Concrete Decks",
["CON-STR.1"]);
acc.addMilestone("MS-roughin", "PH-mep", "Rough-In",
["CON-INS.1"]);
acc.addMilestone("MS-firesup", "PH-mep", "Fire Suppression",
["CON-SAF.1", "CON-INS.1"]);
acc.addMilestone("MS-insulation", "PH-finishes", "Insulation",
["CON-INS.1", "CON-ENV.1"]);
acc.addMilestone("MS-envelope", "PH-finishes", "Envelope",
["CON-STR.1"]);
acc.addMilestone("MS-systems", "PH-commissioning", "Systems Testing",
["CON-INS.1", "CON-SAF.1"]);
acc.addMilestone("MS-final", "PH-commissioning", "Final Inspection",
["CON-FIN.1", "CON-INS.1"]);
// Record inspections
acc.addLeaf("MS-erosion", "a1b2c3d4e5f6", "CON-ENV.1", "PASS");
acc.addLeaf("MS-grading", "b2c3d4e5f6a1", "CON-INS.1", "PASS");
// Check gate
const gate = acc.checkGate("PH-site-prep");
console.log(gate.passed); // true
// Foundation with remediation
acc.addLeaf("MS-footings", "c3d4e5f6a1b2", "CON-STR.1", "PASS");
acc.addLeaf("MS-footings", "d4e5f6a1b2c3", "CON-INS.1", "PASS");
acc.addLeaf("MS-waterproof", "e5f6a1b2c3d4", "CON-ENV.1", "PASS");
acc.addLeaf("MS-drainage", "f6a1b2c3d4e5", "CON-ENV.1", "FAIL");
acc.addLeaf("MS-drainage", "a2b3c4d5e6f7", "CON-ENV.1", "PASS");
console.log(acc.checkGate("PH-foundation").passed); // true
console.log(acc.structureRoot); // single hash
// Verify any attestation offline
const proof = acc.getMultiTierProof("c3d4e5f6a1b2");
console.log(verifyMultiTierProof("c3d4e5f6a1b2", proof!)); // trueSWT3 phase-gate witnessing does not replace building codes, safety standards, or contract documents. It records evidence from the inspections and approvals that those standards require. The protocol is the witness, not the inspector.
CON-SAF.1 maps directly to OSHA 1926 subparts: Subpart M (Fall Protection), Subpart L (Scaffolds), Subpart CC (Cranes), Subpart P (Excavations). Each safety inspection required by the competent person standard becomes an attestation leaf. The phase-gate structure ensures that safety inspections are completed before work proceeds to the next phase, creating a tamper-evident record of the GC's OSHA compliance program.
Building inspections required by the IBC (Chapters 1-17) map to CON-STR.1 and CON-INS.1. The AHJ's inspection sequence -- footings, framing, insulation, final -- aligns naturally with phase-gate milestones. The protocol records the same inspections the AHJ already requires; it adds cryptographic proof of sequence and completeness.
AIA A201 (General Conditions) Section 9 governs payments and completion. The architect's Certificate for Payment (AIA G702) certifies that work is complete to a specified percentage. CON-FIN.1 links the architect's certification to the underlying inspection evidence, creating a verifiable chain from inspection to certification to payment. AIA A201 Section 14 (Termination) proceedings can reference the structure root to establish exactly where the project stood at the time of termination.
ConsensusDocs 200 (Standard Agreement) and ConsensusDocs 750 (Standard Form of Guarantee) both reference progress payment procedures. Phase-gate proofs provide the bonding company and lender with the same evidence the contractor uses for pay applications, eliminating information asymmetry between parties.
Mechanic's lien rights are governed by state law and typically attach at the time of first furnishing labor or materials. The phase-gate timeline provides a cryptographically anchored record of when specific work was performed, when inspections occurred, and when payments were released. In a lien dispute, the Merkle proof provides an independent, tamper-evident timeline that no party can unilaterally alter after the fact.