Tx-Rails for Construction
Tx-Rails for Construction IIoT (Industrial Internet of Things)
Continuous cryptographic audit for the construction site — without ripping out your project-controls stack, your plant-telematics platform, your common data environment, or your defect-management tooling.
A modern construction project sits at the intersection of fast-moving plant, immovable safety regulators, multi-tier subcontract chains, and a procurement world that wants Scope-3 carbon to the kilogram of rebar. The standards have multiplied: ISO 19650 for information management, ISO 45001 for occupational health and safety, BS 8536 for handover-to-operate, the UK Building Safety Act’s golden-thread requirement, NSW Design and Building Practitioners Act compliance evidence, FIDIC / NEC / JCT contract notice-clocks, EN 1090 for structural steel CE-marking, and the EU CSRD-aligned embodied-carbon disclosure regime now landing on every public-sector contract. Each obligation lands on the same site data — plant telematics, lift records, concrete batch tickets, weld certs, soil-compaction passes, environmental monitors — and asks the same question: “prove this happened, prove it wasn’t tampered with after the fact, prove the timeline matches the as-built record.”
Tx-Rails is the substrate that makes those proofs cryptographic. It sits underneath your existing project-controls software (Aconex, Procore, Asite, Viewpoint, Autodesk Construction Cloud, RIB CX), your plant-telematics platform (CAT VisionLink, Komatsu KOMTRAX, Volvo CareTrack, Trimble WorksManager, Topcon Sitelink3D), your defects platform (Snagar, FieldView, BuildBinder), your H&S registers (HSI, Procore Quality+Safety, SHE Software), and your common data environment — binding to them via change-data-capture or atomic dual-write — and produces a tamper-evident, jurisdiction-independent audit trail for every event a regulator, principal contractor, insurer, certifier, or building-safety inspector would want to verify. We do not replace your existing stack. We make its outputs cryptographically provable.
What we capture
The day-to-day site data — every minute-by-minute machine-position fix, every continuous noise-meter reading, every individual frame of the site-perimeter CCTV — stays in your telematics platform and your CCTV NVR. That’s where it belongs. Tx-Rails captures the events derived from that stream that have audit consequence.
Plant & Equipment Provenance
- Plant registration — every excavator, dozer, crane (tower / mobile / crawler), MEWP, telehandler, concrete pump, batching plant, paver, road header, TBM, piling rig, generator, and powered access platform catalogued with manufacturer / model / serial / hours / last-LOLER / last-PUWER / RPE protocol, location, current operator
- Sensor channel definitions — every load-cell, tilt sensor, wind anemometer, vibration logger, dust monitor, noise meter, gas-detector channel, with unit, range, sample rate, warning + alarm thresholds, calibration-due date
- Firmware / GPS / RTK base updates with hash and signature verification — provenance for the telematics-supply-chain risk surface
- Plant-controller program changes captured separately with checksum verification — the integrity-of-control-systems concern under the new connected-plant regulations
Quality & Materials
- Calibration events for every instrument, with traceability to NIST / NMI / UKAS / NATA reference standards, pre and post deviation, next-due date — ISO 17025-class evidence
- Concrete batch tickets — every truck, slump test, cube cast, lab-tested 7/28-day strength, with batching-plant ID, mix design, delivery time, dispatched volume, water-cement ratio, admixtures, ambient + delivered temperature
- Steel reinforcement — bar-bending schedule, mill certificate (EN 10080 / AS/NZS 4671), cut + bend location, fix location, fixer ID, inspection sign-off
- Structural steel — CE / UKCA marking, EN 1090 execution class, welder qualification, weld procedure, NDT result (radiographic / ultrasonic / dye-penetrant), inspector ID
- Soil compaction — each pass logged from the roller’s compaction-control system, with target density, achieved CMV/MDP, location coordinates, layer thickness, geotech sign-off
- Asphalt / aggregate / geosynthetic materials with consignment notes, supplier batch references, on-site temperature at delivery, lay temperature, density tests
- Anomaly events — concrete strength below acceptance criterion, weld defect detected, compaction failure, geotech mismatch, dimensional deviation flagged from BIM-clash detection
Lifting & High-Risk Operations
- Lift plans with crane configuration, load, radius, rigging, wind-speed limit, exclusion zone definition, lift supervisor + slinger-signaller + appointed-person identities, lift category (basic / standard / complex)
- Lift execution events from anti-collision / load-moment-indicator systems — actual radius, actual load, actual wind speed, duration, deviation events, overload alarms, slewing into exclusion zone
- Confined-space entry — atmospheric monitoring (O₂, LEL, H₂S, CO) before and during entry, sentry identity, entry / exit times, permit reference
- Hot work permits — fire-watch identity, atmospheric LEL, extinguisher location, permit window, post-work observation period
- Permit-to-work events generally with issuer, recipient, isolations, validity window, hand-back state
People, Authorisation & Competence
- Site induction — every worker, every visitor, every delivery driver, with photo-ID hash, induction version, induction date, valid-until
- Competency cards — CSCS / CCDO / IPAF / PASMA / CPCS / NPORS (UK), VOC / RTW (AU), with card type, level, expiry, scope of work authorised
- Toolbox talk attendance — talk reference, presenter, attendee list (signed-in via hash), date, location, language-of-delivery
- RAMS / SWMS sign-offs — operative acknowledgement of risk-assessment + method statement before task commencement, version reference
- Operator-to-plant binding — which operator was logged-in to which plant item, at what time, with credentials verified via the plant’s keyfob / biometric / pin reader
Safety & Environmental Events
- Incident events — first-aid, RIDDOR-reportable injury, dangerous occurrence, near-miss, environmental discharge, with severity, root-cause classification, corrective action, regulator-notification status
- Alarm events with severity (Info / Warning / Alarm / Critical / Emergency, aligned with ISA-18.2-equivalent site philosophy)
- Operator acknowledgement of alarms — who saw the alarm, when, what action they took, whether they escalated
- Environmental telemetry aggregates — dust (PM10/PM2.5) hourly, noise dB(A) per shift, ground-water level, neighbour-complaint correlation events
- Waste stream tracking — every skip / waste-transfer note from cradle to disposal-licence holder, EWC code, weight, hazardous-waste classification, end-disposal certificate
- Carbon events — embodied carbon per material consignment (mill-cert backed), operational fuel/electricity consumption per shift per plant item, deliveries-to-site emissions
Project Records
- As-built deviations — every clash between design model and installed work, with location, dimension, photographic evidence hash, change-control disposition
- Snag / defect events — defect identification, severity, responsible trade, expected resolution date, actual resolution date, retest verification
- Variation orders — instruction reference, scope, rate basis, contractor acknowledgement, principal-agent valuation, payment-certificate linkage
- Compliance attestations — ISO 19650, ISO 45001, ISO 14001, BS 8536, BS 9999, EN 1090, Building Safety Act golden-thread evidence packages, BREEAM / LEED / Green Star scorecard inputs
- Data integrity checks — gaps, timing anomalies, sequence breaks, late data, out-of-order samples on any of the above; missing telemetry is itself audit-bearing
- Cybersecurity events — auth failures on plant / site-office networks, firmware verification failures, unauthorised remote-access attempts on telematics, anomalous traffic; forensic timeline that survives local-log tampering
How you integrate
Tx-Rails is a substrate, not a replacement. You connect to your federations in one of four modes:
The four modes
| Mode | What customer does | Metadata fidelity | Use case |
|---|---|---|---|
| A. Hash-only | Nothing; tx-rails computes row-hash from CDC | 22 / 31 fields, no semantic intent | Low-stakes flows where the audit just needs “this row existed at time T” |
| B. CDC observation | Adds Debezium / equivalent to their DB; nothing in the app | 25–27 / 31 (CRUD intent from CDC; user/role IF the customer’s table has audit columns) | Mid-stakes flows; most existing apps that already write created_by / modified_by to their rows |
| C. Gateway-mediated | Routes API traffic through the tx-rails gateway; app unchanged | 30 / 31 (gateway sees the HTTP method, the JWT, the body — derives semantic intent from path + verb) | High-value flows; new app deployments where touching the network edge is cheap |
| D. SDK / atomic dual-write | App calls tx-rails alongside its own DB write | 31 / 31 with explicit semantic intent | The very-high-value flows where the customer wants explicit REVERSAL / CORRECTION / RESTATEMENT tagging |
A small operator runs Hash-only against its database records. A Tier-1 utility dual-writes through its modules. An auditor or regulator running a sample audit across 50 entities runs CDC-observer through their statutory submission pipelines — all interoperable on the same underlay.
What we don’t replace
We do not replace your project-controls platform, your CDE, your BIM authoring tool (Revit, ArchiCAD, Tekla), your model-coordination platform (Navisworks, Solibri), your defects manager, your H&S register, your plant-telematics platform, your fleet-management system, your accounting / ERP, your contracts repository, your tender / cost-planning tool (CostX, Bluebeam Revu, Trimble Vico), your scheduling tool (P6, MSP, Asta Powerproject), your subcontractor portal, or any of your plant-side firmware. Every one of those is a deep operational investment your project teams, plant managers, QSs, and engineers understand intimately. Tx-Rails sits underneath them via one of three integration modes — hash-only attestation, atomic dual-write, or change-data-capture observation — and produces continuous cryptographic evidence that the state changes those systems record are real, ordered, and unalterable.
This is the underlay positioning. It is the only positioning that survives a Project Director’s first question: “how much does this slow the site down?” Answer: none.
And no custom front-end at any price
Beyond the systems above, we also do not sell custom transaction-front-end development as a line item — at any price, in any engagement. Tx-Rails ships with three thin operator utilities (operations console, evidence-retrieval portal, trust-management UI) bundled into the platform subscription and skinnable to your branding; these are operator tools, not site-team or supply-chain screens. If your team needs a new screen for the site engineer, the QS, the contracts manager, or the subbie, they build it against our published SDK with our reference connectors — your team owns the result. The “we’ll build you a portal” deal that exists in social-housing pricing reflects that market’s SaaS-incumbent dynamics; it does not apply to construction where the operational platforms are already entrenched.
Indicative pricing
Pricing is per-pyramid + per-federation, calibrated against your deployment Shape (see [federation-trust-model.md](../federation-trust-model.md)). Ranges only — every engagement is scoped before commit:
| Customer profile | Typical deployment | Indicative A$ / year |
|---|---|---|
| Specialist subcontractor or single-site fit-out | 1 pyramid, 1-2 federations (Shape 1) | 50k – 150k |
| Tier-2 contractor or multi-project regional | 1-2 pyramids, 3-5 federations (Shape 2 grouped) | 250k – 700k |
| Tier-1 principal contractor or multi-jurisdiction PFI / PPP / Alliance | 3-5 pyramids, 5-10 federations (Shape 2 or 3 sovereign) | 1M – 3M |
Excluded: integration work by your IT team (your engineers, against our SDK + reference connectors) and any infrastructure you elect to host sovereignly in-house vs on managed nodes. Pilot deployments use a separate timeboxed model (3-month parallel-run, walk-away clause — terms on request).
Three forces, one architecture
Building safety is now a personal-liability regime. The UK Building Safety Act puts the “Accountable Person” and the “Principal Designer” on the hook for the golden thread of information across the design, construction, and occupation of higher-risk buildings — and that thread has to survive scrutiny decades after handover. NSW’s Design and Building Practitioners Act has the same architecture. Continuous cryptographic logging to an independently verifiable substrate is the only mechanism that demonstrably defends those individuals when a coroner, a Building Safety Regulator, or a civil-claim plaintiff asks “what was actually built, who installed it, and was the certifying inspector even on site that day?”
Embodied carbon is a procurement gate, not a sustainability slogan. Public-sector tenders across the UK, EU, Australia, and increasingly New Zealand now require verifiable embodied-carbon disclosure per design-target and as-built — typically backed by EN 15978 or ISO 21930 lifecycle accounting. The mill certificate behind every tonne of rebar, the EPD behind every concrete mix, the fuel-burn behind every plant item, all have to reconcile. The contractor that can publish cryptographically signed evidence — not a spreadsheet — has a procurement advantage. The contractor that can’t is losing bids to one that can.
Insurance is repricing construction risk in real time. Latent-defects insurers (NHBC, Premier Guarantee, Zurich, SwissRe) and PI insurers are tightening underwriting against contractors who can’t produce a verifiable as-built record. The contractor whose archive is a folder of PDFs and a CCTV NVR is increasingly uninsurable on Tier-1 work; the contractor with a cryptographically provable as-built trail prices a different premium.
Architecture, briefly
- Off-chain — Your CDE. Your BIM models. Your telematics platform. Your CCTV. Your high-resolution geotech survey. We do not duplicate any of that data.
- On-chain — The audit-bearing events derived from that data: plant registration, calibrations, lift plans + executions, concrete + steel + soil-compaction acceptances, weld + NDT results, permits, alarms, incidents, environmental aggregates, waste-transfer notes, variation orders, snag resolutions, compliance attestations, data-integrity checks, cyber events.
- Anchored — Every block of audit events is committed to a Byzantine-fault-tolerant validator mesh and periodically anchored to a public DLT (Hedera) for jurisdiction-independent verifiability. A future building-safety inspector, a coroner, a defects-claim assessor, or an M&A diligence team can verify the audit trail’s integrity without trusting the contractor at all.
The on-chain audit volume is bounded by event rate, not by telemetry rate. A megaproject with 1,200 plant items emitting 1 Hz telematics produces a few tens of thousands of audit-bearing events per day, not 1,200 × 86,400.
A note on the trust boundary
The conventional approach to construction site evidence is to log everything to the project’s CDE and trust the principal contractor. That works until the principal contractor is the one whose conduct is being investigated. The conventional approach to integrating a public blockchain is to put the data on it. That works for nothing at construction-site volume.
Tx-Rails takes a third path: a Byzantine-fault-tolerant audit mesh, owned and operated by the project’s joint-venture or the principal contractor, with independent auditor nodes that don’t share a failure domain with the workload nodes. Periodic cryptographic anchors are published to a public DLT for jurisdiction-independent verifiability. The trust boundary is exactly where it should be — at the math, not at the site office.
Tx-Rails Smart Contracts for Construction
Pay-on-pour concrete settlement, automated plant-hire billing, cascading subcontractor payments, variation auto-acceptance, retention release, LD calculation, embodied-carbon attestation, and insurance-bonded warranty execution — all running as self-executing multi-party contracts with full audit trail.
A construction project is a temporary multi-party joint enterprise. A principal contractor signs with the client; subcontractors sign with the principal; sub-subcontractors sign with the subbies; plant hirers, materials suppliers, agency labour, consultants, design teams, certifiers, building-control bodies, insurers, retention-bond providers, latent-defects insurers, and warranty providers each sign with somebody. Every agreement specifies what triggers payment, what triggers a notice clock, what triggers an extension of time, what triggers liquidated damages, what triggers release of retention, and what triggers a defects-liability obligation. Almost none of that execution is automated. The result is the construction industry’s two most expensive line items: disputed-payment working capital and adjudication legal fees, both of which Carillion-style insolvencies have only intensified.
Tx-Rails turns those agreements into on-chain smart contracts that execute themselves when their conditions are provably met. IIoT site telemetry triggers condition resolution; multi-party signatures release escrowed funds; concrete acceptance, lift completion, snag closure, certifier sign-off, and milestone events drive payment automatically — all recorded with cryptographic evidence of which contract clause fired, which event triggered it, and who the counterparties were.
Tx-Rails’ “smart contracts” are not Ethereum-style EVM contracts. They’re declarative business processes composed from the platform’s action layer, the workflow sequencer (PILLAR 15), per-network policy hooks, and BFT-consensused multi-party transactions with M-of-N commitment groups. Same trust semantics; lower gas cost; native interoperability with the rest of your operational data — including the as-built record from the companion IIoT layer.
What you can now automate
Pay-on-pour concrete settlement
A ready-mix supplier delivers an A$2.4M / week stream of concrete across multiple pours, multiple sites, multiple grades. Today: each truck’s docket goes to site, the engineer marks it accepted-conditionally-on-cube-result, the cube tests come back 7 + 28 days later, the supplier waits for payment, the QS chases the variation if grade was substituted, and disputes accumulate.
With tx-rails:
- The supply contract is a multi-party transaction between the principal contractor, the ready-mix supplier, the third-party testing laboratory, and (on PFI / Alliance jobs) the independent certifier.
- Per delivery, payment is held in escrow at GRN — sized to the delivery’s nominal value at the contract rate for that grade.
- A release condition is attached: “lab cube-strength result at 28 days ≥ characteristic strength of the specified grade” — predicate evaluates against the lab’s signed test report.
- When the 28-day cube comes back PASS, a workflow rule fires within the same block: condition MET → escrow releases → AP posts payment to the supplier with full dimensional accounting (cost centre, project, work breakdown structure, sub-WBS) preserved.
- A 28-day FAIL → condition FAILED → workflow auto-opens a quality dispute, the funds remain frozen, the affected pour is flagged in the as-built register, and the principal designer is notified for structural reassessment.
The 28-day delay is removed at the working-capital level only — the supplier sees same-block settlement on every pour that ultimately passes, instead of holding 6+ weeks of pours hostage to one disputed truck.
Plant-hire automated billing
A contractor hires a 70-tonne crane on a four-week wet-hire contract: A$X per shift up to 50 hours, A$Y per shift above. Today: the hire company invoices on its own logged hours, the site superintendent disputes them on the basis of the operator’s time-card, both reconcile by month-end with a 5-10% friction loss baked in.
With tx-rails: the crane’s load-moment-indicator and the operator-keyfob logs emit hourly telemetry aggregates (operator-on hours, idle hours, hook-time hours, anomaly count) to the ledger. A workflow rule matches each aggregate against the hire contract, computes the tier-aware shift charge, and auto-fires an invoice action against the principal contractor’s payment terms. The hire company’s CFO sees revenue recognised against actual usage; the contractor’s QS sees an invoice that resolves to specific telemetry-aggregate IDs; the auditor sees the rule, the predicate, and the matched event recorded in the same block. The 5-10% friction is recoverable margin on both sides of the contract.
Cascading subcontractor payment
A principal contractor’s milestone payment from the client is A$6.4M. The principal’s payment obligations downstream cascade: A$1.8M to the M&E subcontractor, A$0.9M to the structural-steel subcontractor, A$0.4M to the formwork subcontractor, and from each of those to their own sub-subbies and materials suppliers. Today: payment cascades by phone and email, with tier-3 paid 60-90 days after tier-1 receives, even though the milestone evidence is identical.
With tx-rails: each tier’s payment is a commitment group keyed to a verifiable upstream milestone (zone-level snag-closure, structural-acceptance certification, certifier sign-off, retention threshold). The sub-subbie’s payment from the subbie is an escrow that auto-releases when the subbie’s own GRN action records receipt-with-acceptance; the subbie’s payment from the principal auto-releases when the principal’s own client-certified-milestone assertion lands; the principal’s payment to the subbie inherits the trust semantics of the client’s certificate. Working capital across the supply chain compresses from quarter-end reconciliation to same-block settlement — and the Construction Act / Building & Construction Industry Security of Payment Act statutory notice-clocks run against verifiable on-chain timestamps, removing the most common adjudication trigger.
Variation-order auto-acceptance against pre-agreed rates
The client instructs an architectural variation worth approximately A$120K of additional formwork and rebar. Today: the principal contractor issues a notice within the contractual clock, the QS valuations are agreed weeks later, the variation is then disputed at year-end final-account because someone claims the rate basis wasn’t the contract schedule.
With tx-rails: the contract includes a rate schedule registered as on-chain reference data at signing. A workflow rule matches the variation instruction, looks up the relevant rates, computes the value, and auto-issues the variation request to the principal — with rate provenance verifiable back to the signed schedule. The client signs the request; the variation is automatically valued in the next interim valuation; final-account disputes are bounded to scope (was the work actually done?) rather than rate (was the QS right?).
Retention release after defects-liability period
A principal contractor’s retention bond on a A$60M contract is A$1.8M (3%) held against a 12-month defects-liability period. Today: the retention sits in a bank account; the principal chases the client at 12 months + 1 day; the client points to outstanding snags as reason to extend; the matter drags into year 14 or 15 with bond costs accruing to the principal.
With tx-rails: the retention is an escrow with two release predicates: (a) defects-liability-period-elapsed = true (time-based, auto-resolves at month 12), AND (b) open-snags-count = 0 (predicate over the on-chain snag register, including the closure-evidence hash from the snagger’s app + certifier’s signature). When both predicates evaluate true, the workflow rule auto-releases the retention. Bond costs evaporate; the dispute surface shrinks to legitimate defects (which are visible to both parties on the same ledger) rather than process-of-release.
Liquidated-damages auto-calculation against milestone slip
A schedule milestone slips. Today: the client’s contracts manager calculates LDs from the milestone-late date to the actual-achievement date at the contract rate, the principal disputes the milestone-actual date and the calculation method, both sides argue for months.
With tx-rails: the milestone date and the milestone-actual date are both on-chain events; the LD rate is on-chain contract data. A workflow rule computes LDs deterministically the moment the milestone-actual lands, posts the LD as a charge against the next payment-certificate, and references the underlying event IDs. Dispute is bounded to “was this milestone genuinely achieved?” — a question of evidence, not arithmetic.
Embodied-carbon attestation with material-pass-through
The client’s tender requires sub-300 kg-CO₂e/m² embodied carbon, with verifiable backing for every consignment of structural material. Today: a sustainability consultant produces a spreadsheet at handover, with assumptions that lose evidence trail back to specific deliveries.
With tx-rails: each material consignment is a transaction carrying its EPD reference, the mill / batch ID, the per-tonne carbon factor, and the delivered tonnage. A workflow rule aggregates monthly per-element + per-zone carbon totals; at handover, the project’s embodied-carbon report is a deterministic computation against the on-chain consignment log. The certifier can verify the report by replaying the rule against the source consignments, not by trusting the consultant’s spreadsheet.
Insurance-bonded warranty execution
A latent-defects insurer underwrites a 12-year warranty on a structural element. Year 4: a defect emerges. Today: the building owner files a claim, the insurer disputes whether the defect is workmanship (covered) or design (excluded), evidence packs are assembled from PDFs and scanned drawings, the claim takes 18-24 months.
With tx-rails: the warranty is a multi-party contract between insurer, principal contractor, principal designer, and building owner. The on-chain as-built record (see companion IIoT layer) carries the install evidence — installer ID, materials provenance, certifier sign-off, post-install QA. A workflow rule triggered by a registered defect event navigates the evidence chain automatically: install was per-design → covered; install deviated from design → designer’s policy; install used uncertified materials → contractor’s policy. Settlement timeframe compresses from 18-24 months to weeks.
Why this matters
Working capital is the construction industry’s most expensive consumable. Every day a payment is held up by manual quality-verification, milestone-sign-off, or retention-release haggling is a day of working-capital cost the principal contractor finances and ultimately prices into the next bid. Subbies finance it at higher rates; sub-subbies at credit-card rates. Automating the release the moment the condition is provably met shrinks that cycle from months to blocks — and recovers the financing overhead that currently sits invisibly in every tender.
Adjudication is a structural drain. Under the UK Housing Grants Act, the AU Security of Payment Acts, and the NZ Construction Contracts Act, statutory adjudication is meant to be a quick fix for payment disputes. In practice, the legal cost of each adjudication is 5-7 figures and the relationship damage between counterparties is permanent. When the underlying payment trigger is a deterministic workflow rule against a co-signed contract, the adjudication surface collapses to genuine scope disputes — a small fraction of current volume.
The supply chain became too long to trust. A modern megaproject has tens of thousands of subcontractor and supplier counterparties. The principal contractor never really knew what sub-tier compliance looked like, because sub-tier evidence was opaque and sub-sub-tier was invisible. With each tier’s actions recorded on the same multi-party ledger, the principal can write smart contracts that depend on tier-N events without trusting tier-N’s IT.
Insurance is repricing the wrong end of the risk. Latent-defects, PI, and CAR insurers are tightening underwriting against contractors whose evidence pack is folder-of-PDFs. The contractor with a cryptographically provable as-built and a deterministic warranty-execution path prices a fundamentally different premium — and is increasingly the only contractor underwriters will quote at all on Tier-1 work.
The audit is built in. Every auto-fired payment, every released escrow, every triggered workflow rule has a cryptographic provenance record. Building Safety Regulator inquiries, coroner’s inquests, defects-claim assessments, ISO 19650 information-management audits, and embodied-carbon assurance audits can verify a year’s worth of project activity without trusting anyone’s internal spreadsheets or scanned PDFs.
What this doesn’t replace
We don’t replace your project-controls platform, your CDE, your BIM tooling, your QS / cost-planning software, your scheduling tool, your defects manager, your H&S register, your plant-telematics platform, your subcontractor portal, your accounting / ERP, your contracts repository, your retention-bond provider, or your insurance broker. Tx-Rails sits underneath all of them as the multi-party-aware execution substrate. The smart contracts run as on-chain logic against the events your existing systems already produce; the payments post back into your ERP via the dimensional-accounting layer so your CFO sees normal journal entries with full provenance back to the underlying site event.
And no custom front-end at any price
We also do not sell custom transaction-front-end development as a line item — at any price, in any engagement. Tx-Rails ships with three thin operator utilities (operations console, evidence-retrieval portal, trust-management UI) bundled into the platform subscription and skinnable to your branding; these are operator tools, not site / subcontractor / supplier screens. If your team needs a new screen for the QS, the contracts manager, the subbie, or the materials supplier, they build it against our published SDK with our reference connectors — your team owns the result. The “we’ll build you a portal” deal that exists in social-housing pricing reflects that market’s SaaS-incumbent dynamics; it does not apply to construction where every operating platform already ships portal-grade UI.
Indicative pricing
Pricing is per-pyramid + per-federation, calibrated against your deployment Shape (see [federation-trust-model.md](../federation-trust-model.md)). Ranges only — every engagement is scoped before commit:
| Customer profile | Typical deployment | Indicative A$ / year |
|---|---|---|
| Specialist subcontractor or single-site fit-out | 1 pyramid, 1-2 federations (Shape 1) | 50k – 150k |
| Tier-2 contractor or multi-project regional | 1-2 pyramids, 3-5 federations (Shape 2 grouped) | 250k – 700k |
| Tier-1 principal contractor or multi-jurisdiction PFI / PPP / Alliance | 3-5 pyramids, 5-10 federations (Shape 2 or 3 sovereign) | 1M – 3M |
Smart-contract automation (pay-on-pour, plant-hire billing, cascading subcontractor payments, retention release, variation acceptance, LD calculation, embodied-carbon attestation, warranty execution) is included in the platform subscription — there is no per-contract or per-execution charge. Volume scales with federation participants, not with contract throughput. Excluded: integration work by your IT team (your engineers, against our SDK + reference connectors) and any infrastructure you elect to host sovereignly in-house vs on managed nodes. Pilot deployments use a separate timeboxed model (3-month parallel-run, walk-away clause — terms on request).
What we’d ask of you to start
A single trade package on a single live project — typically concrete or structural steel because their acceptance criteria are well-defined and their batch-record / mill-cert provenance is already digital. Read the audit-significant events out of your CDE + the batching plant’s API + the telematics platform via change-data-capture; flow them through tx-rails for one trade, one month. At the end of the month you have a cryptographically verifiable audit trail of every concrete pour, every cube break, every steel-fix sign-off, every lift, every compaction pass, every variation, every operator-card check. We then have a real conversation about what that’s worth on your next building-safety inspection, your next embodied-carbon-disclosure tender, or your next latent-defects insurance renewal.
See the companion column — Tx-Rails for Construction IIoT — for the cryptographic-audit capture layer that produces the events these smart contracts consume.
Contact:john@itotchaincloud.com.au
Tx-Rails — Built by IT/OT Chain & Cloud Australia (ITOTCCA). Sydney · London.