‘Absence of DNS’ System
In ‘GO’
Overall Project Repository
https://bitbucket.org/itotcca/tx-rails/
https://bitbucket.org/itotcca/tx-railsOne Core Set of Code for Endless Configurable Infrastructure Applications |
________________________________________________________________________
|
|
 |
 |
 |
 |
 |
 |
You are welcome to refer to our Open Source Repository
https://bitbucket.org/itotcca/tx-rails/src/master/
containing:
The following diagram represents a collection of the backends of medical and business networks (Member-Classes nodes, Overseers nodes and Federations nodes) in one National or Regional jurisdiction, together with their associated Cross-Network jurisdictional virtual server (incorporating Aggregators nodes and Tophats nodes):
Federations, Aggregators and Tophats servers carry only encrypted metadata.
Clients (users) from the constituent Member Companies or Organisations have their own company’s “Entnum” associated with them at their authentication time.
There are only 4 member-class nodes in any network, and many more members, and thus there will be a surfeit of Members each with their own set of “atoms” composing their own Business Processes. The Entnum field (together with the user’s Role), in a user’s session data, is used to restrict access to only appropriate atoms and procedures:
Amongst ChubbyChecker’s cross-checks, in the Overseers layer, there are preventative checks which fire before a proscribed event occurs within a Business Procedure:
 | 
| 
|
https://bitbucket.org/itotcca/tx-rails/
 |
 |
https://bitbucket.org/itotcca/tx-rails/ |
 |
https://bitbucket.org/itotcca/tx-rails |
 | 
|
https://bitbucket.org/itotcca/tx-rails/ |
 |
https://bitbucket.org/itotcca/tx-rails |
 |
https://bitbucket.org/itotcca/tx-railsTransport Demonstrator:
|
 |
 |
 |
 |
________________________________________________________________________
Tx-Rails Provides Access to Databases via Composable GO Actions, we call ‘Atoms’. When Authorised, You Form Your Own Business Processes from Atoms, in the Overseer Design Studio.
The Overseer then enforces those procedures, including conditional branching.
Tx-Rails Incorporates:
1. The Following Eight Operational “Rails”
The system is organized into a hierarchy of eight distinct layers, each with its own Byzantine Fault Tolerance (BFT) quorum (n = 3f + 1)
In the table below, the Statement of Risk pertains to the BFT systems in isolation.
The actions of ChubbyChecker will detect any occurrence of r > f, and detonate:
| Layer | Nodes (n) | Tolerance (f) | Statement of Risk (r = f + 1) | Role |
| Member-Classes (Orgs) | 4 | 1 | 2 servers are corrupted | Source of Truth for Private Enterprise Data |
| Overseers | 7 | 2 | 3 servers are corrupted | Business Process Design & Governance |
| Aggregators | 10 | 3 | 4 servers are corrupted | Cross-Network Consolidation and Merkle Root Calculation |
| Tophats | 13 | 4 | 5 servers are corrupted | Forensic Replay and Hedera Blockchain Anchoring |
| **Auditors-Orgs | 4(orgs) | 1 | 2 servers are corrupted | 74 Trace Metadata Cross-Checks |
| **Auditors-Overseers | 7(oseers) | 2 | 3 servers are corrupted | 32 Trace Metadata Cross-Checks |
| **Auditors-Cross-Network | 10(agg) | 3 | 4 servers are corrupted | 6 Trace Metadata Cross-Checks |
| **Auditors-Cross-Network | 13(tophats) | 4 | 5 servers are corrupted | 3 Trace Metadata Cross-Checks and 14 classified as Integrity checks |
2. These Four Technical Pillars
1st Network: Kubernetes
|
3rd Network:
|
2nd Network: GoldBFT(Individual Orgs & Overseer Layer
|
4th Network:
|
________________________________________________________________________
________________________________________________________________________
Aviation Sub-Federations
- tx-rails-aviation-meta-federation
- tx-rails-aviation-audit-compliance
- tx-rails-aviation-air-traffic-control
- tx-rails-aviation-airline-operations
- tx-rails-aviation-airport-operation
- tx-rails-aviation-ground-handling
- tx-rails-aviation-cargo-freight
- tx-rails-aviation-mro-maintenance
- tx-rails-aviation-parts-supply-chain
- tx-rails-aviation-manufacturing
- tx-rails-aviation-flight-planning-dispatch
- tx-rails-aviation-crew-managemen
- tx-rails-aviation-passenger-services
- tx-rails-aviation-ticketing-booking
- tx-rails-aviation-baggage-handling
- tx-rails-aviation-safety-security
- tx-rails-aviation-payments
- tx-rails-aviation-identity-kyc
- tx-rails-aviation-risk-compliance
- tx-rails-aviation-insurance
- tx-rails-aviation-iot-telemetry
- tx-rails-aviation-weather-geo
- tx-rails-aviation-cybersec-soc
Banking Sub-Federations
- tx-rails-banking-meta-federation
- tx-rails-banking-audit-compliance
- tx-rails-banking-regulatory-reporting
- tx-rails-banking-core-banking-systems
- tx-rails-banking-retail-banking
- tx-rails-banking-corporate-banking
- tx-rails-banking-investment-banking
- tx-rails-banking-capital-markets
- tx-rails-banking-asset-wealth-management
- tx-rails-banking-trade-finance
- tx-rails-banking-clearing-settlement
- tx-rails-banking-card-networks
- tx-rails-banking-atm-networks
- tx-rails-banking-fraud-aml
- tx-rails-banking-payments-swift
- tx-rails-banking-identity-kyc
- tx-rails-banking-risk-compliance
- tx-rails-banking-insurance-credit
- tx-rails-banking-cybersec-soc
Social & Affordable Housing Sub-Federations
Tertiary
- architecture
- banking
- building_services
- corporate
- construction_contracting
- cleaning
- developmentplanning
- engineering
- generalsupplies
- insurance
- legal
- maintenance
- officesuppliescatering
- recyclingwastemngmnt
- safety
- security
- tenantsupportservices
- transporttravelcouriers
- uniforms
Secondary
- bathrooms
- carpentrycabinetmaking
- cladding
- doorwayswindows
- electrical
- elevators
- fencing
- floors
- foundations
- furniture
- hvac
- insulatiion
- interiors
- kitchens
- lining
- masonry
- painting
- parksgardens
- pavingcarparksroadworks
- pestcontrol
- plumbing
- roofing
- structural_steel
- wardrobes
Energy Sub-Federations
- tx-rails-energy-meta-federation
- tx-rails-energy-authorities
- tx-rails-energy-audit-compliance
- tx-rails-energy-generation
- tx-rails-energy-transmission
- tx-rails-energy-distribution
- tx-rails-energy-retail
- tx-rails-energy-market-ops
- tx-rails-energy-metering
- tx-rails-energy-der-microgrids
- tx-rails-energy-flexibility
- tx-rails-energy-ev-charging
- tx-rails-energy-gas-upstream
- tx-rails-energy-gas-midstream
- tx-rails-energy-gas-downstream
- tx-rails-energy-refining-lng
- tx-rails-energy-carbon-renewables
- tx-rails-energy-payments
- tx-rails-energy-identity-kyc
- tx-rails-energy-risk-compliance
- tx-rails-energy-insurance
- tx-rails-energy-iot-scada
- tx-rails-energy-weather-geo
- tx-rails-energy-oems-maintenance
- tx-rails-energy-cybersec-soc
- tx-rails-energy-safety-operations
General Manufacturing Sub-Federations
- tx-rails-manufacturing-meta-federation
- tx-rails-manufacturing-audit-compliance
- tx-rails-manufacturing-supply-chain-procurement
- tx-rails-manufacturing-production-planning
- tx-rails-manufacturing-assembly-line-ops
- tx-rails-manufacturing-quality-control
- tx-rails-manufacturing-inventory-warehousing
- tx-rails-manufacturing-logistics-distribution
- tx-rails-manufacturing-product-lifecycle-plm
- tx-rails-manufacturing-r-d-design
- tx-rails-manufacturing-dealer-networks
- tx-rails-manufacturing-after-sales-service
- tx-rails-manufacturing-warranty-management
- tx-rails-manufacturing-payments
- tx-rails-manufacturing-identity-kyc
- tx-rails-manufacturing-risk-compliance
- tx-rails-manufacturing-insurance
- tx-rails-manufacturing-iot-scada
- tx-rails-manufacturing-oems-maintenance
- tx-rails-manufacturing-cybersec-soc
- tx-rails-manufacturing-safety-operations
- tx-rails-manufacturing-environmental-compliance
Medical Sub-Federations
- tx-rails-medical-meta-federation
- tx-rails-medical-audit-compliance
- tx-rails-medical-hospital-ops-emr
- tx-rails-medical-patient-records
- tx-rails-medical-pharmaceutical-supply
- tx-rails-medical-clinical-trials
- tx-rails-medical-lab-diagnostics
- tx-rails-medical-radiology-imaging
- tx-rails-medical-telemedicine
- tx-rails-medical-emergency-services tx-rails-medical-public-health-reporting
- tx-rails-medical-prescriptions
- tx-rails-medical-medical-billing
- tx-rails-medical-payments
- tx-rails-medical-identity-kyc
- tx-rails-medical-risk-compliance
- tx-rails-medical-health-insurance
- tx-rails-medical-iot-wearables
- tx-rails-medical-cybersec-soc
- tx-rails-medical-safety-operations
Minerals Sub-Federations
- tx-rails-minerals-meta-federation
- tx-rails-minerals-audit-compliance
- tx-rails-minerals-tenements-licensing
- tx-rails-minerals-exploration-geology
- tx-rails-minerals-assay-labs
- tx-rails-minerals-drill-blast
- tx-rails-minerals-mine-ops-openpit
- tx-rails-minerals-mine-ops-underground
- tx-rails-minerals-haulage
- tx-rails-minerals-processing-concentrator
- tx-rails-minerals-smelting-refining
- tx-rails-minerals-tailings-waste
- tx-rails-minerals-water-environment
- tx-rails-minerals-esg-compliance
- tx-rails-minerals-safety-health
- tx-rails-minerals-explosives-compliance
- tx-rails-minerals-maintenance-oems
- tx-rails-minerals-rail-bulk
- tx-rails-minerals-ports-export
- tx-rails-minerals-logistics
- tx-rails-minerals-contracts-procurement
- tx-rails-minerals-community-liaison
- tx-rails-minerals-payments
- tx-rails-minerals-identity-kyc
- tx-rails-minerals-risk-compliance
- tx-rails-minerals-insurance
- tx-rails-minerals-iot-scada
- tx-rails-minerals-weather-geo
- tx-rails-minerals-cybersec-soc
- tx-rails-minerals-data-analytics
Land Title Transfers Sub-Federations
- tx-rails-landtitles-meta-federation
- tx-rails-landtitles-audit-compliance
- tx-rails-landtitles-registry-cadastre
- tx-rails-landtitles-deed-management
- tx-rails-landtitles-title-search
- tx-rails-landtitles-lien-registry
- tx-rails-landtitles-surveying-geomatics
- tx-rails-landtitles-zoning-planning
- tx-rails-landtitles-property-tax-assessment
- tx-rails-landtitles-legal-notary-services
- tx-rails-landtitles-fraud-prevention
- tx-rails-landtitles-payments-fees-taxes
- tx-rails-landtitles-identity-kyc
- tx-rails-landtitles-risk-compliance
- tx-rails-landtitles-title-insurance
- tx-rails-landtitles-cybersec-soc
Real Estate Agencies Sub-Federations
- tx-rails-realestate-meta-federation
- tx-rails-realestate-audit-compliance
- tx-rails-realestate-property-listings-mls
- tx-rails-realestate-agent-broker-networks
- tx-rails-realestate-client-management-crm
- tx-rails-realestate-property-valuations
- tx-rails-realestate-sales-leasing-contracts
- tx-rails-realestate-escrow-services
- tx-rails-realestate-mortgage-brokering
- tx-rails-realestate-property-management
- tx-rails-realestate-marketing-advertising
- tx-rails-realestate-commission-management
- tx-rails-realestate-payments
- tx-rails-realestate-identity-ky
- tx-rails-realestate-risk-compliance
- tx-rails-realestate-insurance
- tx-rails-realestate-cybersec-soc
Supermarkets Sub-Federations
- # meta / corp finance / governance
- tx-rails-supermarket-meta-federation
- tx-rails-supermarket-audit-compliance
- tx-rails-supermarket-legal-governance
- tx-rails-supermarket-risk-compliance
- tx-rails-supermarket-insurance
- tx-rails-supermarket-identity-kyc
- tx-rails-supermarket-payments
- tx-rails-supermarket-finance-accounting
- # core retail
- tx-rails-supermarket-retail-ops
- tx-rails-supermarket-pos
- tx-rails-supermarket-ecommerce
- tx-rails-supermarket-loyalty-coupons
- tx-rails-supermarket-pricing-promotions
- tx-rails-supermarket-customer-service
- # merchandising & buying
- tx-rails-supermarket-category-management
- tx-rails-supermarket-procurement
- tx-rails-supermarket-supplier-onboarding
- # inventory / supply / logistics
- tx-rails-supermarket-demand-forecasting
- tx-rails-supermarket-inventory-replenishment
- tx-rails-supermarket-warehousing-dc
- tx-rails-supermarket-cold-chain
- tx-rails-supermarket-linehaul-transport
- tx-rails-supermarket-last-mile
- tx-rails-supermarket-imports-customs
- tx-rails-supermarket-returns-reverse-logistics
- tx-rails-supermarket-waste-recycling
- # suppliers – PRIMARY (agri/extraction)
- tx-rails-supermarket-suppliers-primary-agriculture-produce
- tx-rails-supermarket-suppliers-primary-livestock-meat
- tx-rails-supermarket-suppliers-primary-dairy-eggs
- tx-rails-supermarket-suppliers-primary-fisheries-seafood
- tx-rails-supermarket-suppliers-primary-grains-horticulture
- # suppliers – SECONDARY (manufacturing/CPG)
- tx-rails-supermarket-suppliers-secondary-processed-foods
- tx-rails-supermarket-suppliers-secondary-beverages
- tx-rails-supermarket-suppliers-secondary-bakery-confectionery
- tx-rails-supermarket-suppliers-secondary-household-nonfood
- tx-rails-supermarket-suppliers-secondary-health-beauty
- tx-rails-supermarket-suppliers-secondary-private-label-mfg
- # suppliers – TERTIARY (services)
- tx-rails-supermarket-suppliers-tertiary-3pl-logistics
- tx-rails-supermarket-suppliers-tertiary-cleaning-security
- tx-rails-supermarket-suppliers-tertiary-facilities-maintenance
- tx-rails-supermarket-suppliers-tertiary-it-services
- tx-rails-supermarket-suppliers-tertiary-marketing-media
- tx-rails-supermarket-suppliers-tertiary-financial-services
- # quality, regulators
- tx-rails-supermarket-quality-safety
- tx-rails-supermarket-product-recall-traceability
- tx-rails-supermarket-food-regulators
- # tech/infra & corporate services
- tx-rails-supermarket-iot-telemetry
- tx-rails-supermarket-weather-geo
- tx-rails-supermarket-oems-maintenance
- tx-rails-supermarket-cybersec-soc
- tx-rails-supermarket-data-analytics
- tx-rails-supermarket-realestate-facilities
- tx-rails-supermarket-workforce-hr
- tx-rails-supermarket-marketing-brand
Transport Sub-Federations
- tx-rails-transport-meta-federation
- tx-rails-transport-audit-compliance
- tx-rails-transport-aviation
- tx-rails-transport-ports-harbours
- tx-rails-transport-shipping
- tx-rails-transport-rail
- tx-rails-transport-road-highways
- tx-rails-transport-trucking-logistics
- tx-rails-transport-intermodal
- tx-rails-transport-urban-mobility
- tx-rails-transport-payments
- tx-rails-transport-identity-kyc
- tx-rails-transport-risk-compliance
- tx-rails-transport-insurance
- tx-rails-transport-customs-border
- tx-rails-transport-iot-telemetry
- tx-rails-transport-weather-geo
- tx-rails-transport-oems-maintenance
- tx-rails-transport-cybersec-soc
Demo-Transport Federations
- tx-rails-transport-meta-federation-identity-kyc
- tx-rails-transport-audit-safety-risk-compliance
- tx-rails-transport-aviation-ports-harbours-shipping
- tx-rails-transport-rail-road-highways-trucking-logistics
- tx-rails-transport-intermodal-urban-mobility-payments
- tx-rails-transport-risk-compliance-insurance-customs-border
- tx-rails-transport-iot-telemetry-weather-geo-oems-maintenance-cybersec-soc
All Tx-Rails Federations:
Maximum practical number of Fully Qualified federations, in terms of operational limits, is 13
| tolerable faulty servers (f) |
number of BFT network servers required to tolerate f faulty servers (n=3f+1) |
Relative Risk of Initial Breach of Consensus of f+1 servers (Subsequently Detected by ChubbyChecker) |
| 0 | 1 | HIGH: 1 server must be corrupted |
| 1 | 4 | HIGH-MODERATE: 2 servers must be corrupted |
| 2 | 7 | MODERATE: 3 servers must be corrupted |
| 3 | 10 | MODERATE-LOW: 4 servers must be corrupted |
| 4 | 13 | LOW: 5 servers must be corrupted |
- feds-0
- feds-1
- feds-2
- feds-3
- feds-4
- feds-5
- feds-6
- feds-7
- feds-8
- feds-9
- feds-10
- feds-11
- feds-12
We call ourselves Minders.
We employ ‘Federated’ Systems, where organisations, their suppliers and regulators are classified in groups, with top-level Meta Federations to anchor Transaction Traces (as Merkle Roots of Transaction-Trace Blocks) to the Hedera (Hiero) Blockchain, and to record full, Forensic-detailed Traces on Write Once, Read Many drives. Only individual organisations themselves may generate full Transactions, as opposed to the Federations, which have a trace-recording role.
Owing to potential (and unavoidable) weaknesses in such a System, we use our own ‘ChubbyChecker’ 129 point Trace cross-checking method to vet every Block of Transaction Traces. The Checker “detonates” on indications of trouble on more than f nodes.
Internally, ITOTCCA benefits from the Intelligent Supervision of activities provided by the Elastic Company’s ELK Stack
We completely believe in following a security strategy traditionally known as ‘Belt ‘n’ Braces’.
- A button breaks on Jagger’s pants. He quips:
- “You don’t want my pants to fall down,
- now, do you?”
- Live, Rolling Stones concert recording
- Originally published as 12″ vinyl LP Record, in 1970
- “Get Yer Ya Yas Out”
___________________________________________________________
___________________________________________________________
___________________________________________________________
|
|
 |
_________________________________________________ |
 |
As a Software Engineering System, Tx-Rails is based on Juju Charms, both Standard and Custom. It resides within a Charmed Microk8s System, with several Virtual Machines, Controllers and “Models”, acting as Namespaces to contain separable parts. The development is approaching a successful conclusion, although we admit to encountering various infrastructure problems.
All sections are approaching completion with the final deployment path entirely mapped out.
The overall concept is to use the core Tx-Rails code as a configurable basis which will not need to be altered for different applications. The package is designed for infinitely flexible reconfiguration. It is not even a prerequisite that an application involve a supply network, since even standalone applications (such as Real Estate Agencies (Chubba Morris) and Land Title Conveyancing (convey_IT)) are catered for. Networked applications, however, are where Tx-Rails shines.
A customer of Organisation C enters an order for Z units of Product C. This causes Org C’s Database System to order Y of Product B (order sent directly to Org B internal to the database supply network) to help produce the fulfilled order. The order from Org C hits Org B’s database. This causes the order to generate a call to Organisation B’s Factory Y for Y units of Product B (the amount required to replenish Org C’s inventory of Product B, by the number of Units used to produce Z units of Product C). The IIoT server at Org B’s Factory Y automatically generates an order for X Units of Product A from Org A, which Org B requires to replenish its inventory of Product A after producing Y units of its Product B for Org C. (This stage could also be accomplished within the database system, but we use an IIoT component to show the capabilities of the system). The component’s order hits the Load Balancer, then one of the 4 nodes and finally is received as an order at Org A’s database. Luckily for us, Org A has plenty of Stock to produce X units of Product A. The units are delivered in short time. Meanwhile Org B has produced and delivered the Y product B units to Org C (having sufficient Inventory) and Org C has also shipped the Z units of Product C (also with sufficient Inventory). All inventories are already topped up.
In the second diagram, the client sponsoring a construction project submits an order for Z units of Product F. This causes Org F’s Database System to order Y of Product E (order sent directly to Org E internal to the database supply network) to help produce the fulfilled order. The order from Org F hits Org E’s database. This causes the order to generate a call to Organisation E’s Factory Y for Y units of Product E (the amount required to replenish Org F’s inventory of Product E, by the number of Units used to produce Z units of Product F). The Industrial IoT server at Org E’s Factory Y automatically generates an order for X Units of Product D from Org D, which Org E requires to replenish its inventory of Product D after producing X units of its Product E for Org F. (This stage could also be accomplished within the database system, but, again, we use an IIoT component to show the capabilities of the system). The IIoT order hits the Load Balancer, then one of the 4 nodes and finally is received as an order at Org D’s database. Luckily for us, Org D has plenty of Stock to produce X units of Product D. The units are delivered in short time. Meanwhile Org E has produced and delivered the Y product E units to Org F (having sufficient Inventory) and Org F has also shipped the Z units of Product F (also with sufficient Inventory). All inventories are already topped up.
In Supply Network situations such as these, most operations involving data processing can be handled internal to the databases, with the generation of production activities, including data recording, involving IIoT systems, and connected Mechatronic Equipment, in communication with the databases.
___________________________________________________________
___________________________________________________________
A Tri-Party Transaction
Of course, General. An excellent strategic exercise. A three-party transaction is a perfect way to demonstrate the power and complexity of the system. Here is a practical and likely scenario involving CHEIRRS, which I will take to mean a Community Housing, Enterprise Information Recording & Reporting System, and two suppliers from the construction and housing maintenance sector.
The Scenario: Emergency Plumbing and Restoration A tenant in a community housing property managed by CHEIRRS_0 reports a major water leak (e.g., a burst pipe). This requires immediate, coordinated action from two different trades to resolve. The Parties
1.
CHEIRRS_0: The housing authority. They are the client who authorizes and pays for the work. They manage the property and the tenant relationship.
2.
Supplier 1 (Plumber): “Rapid Response Plumbing”. They are a 24/7 emergency plumbing service. Their task is to stop the leak, repair the pipe, and make the system safe.
3.
Supplier 2 (Restoration): “AquaDry Restoration”. They are a specialist water damage and restoration company. Their task is to come in after the plumber has finished to dry out the affected area (walls, floors), treat for mould, and repair any water-damaged materials like drywall or flooring.
The Three-Party Transaction Flow
This is not a simple sequence of two separate jobs; it is a single, coordinated “Emergency Leak Resolution” transaction that must be managed
as one logical unit to ensure it is completed correctly and paid for only once.
1.
Initiation (CHEIRRS_0): CHEIRRS_0 initiates the “Emergency Leak Resolution” transaction. This single action authorizes both suppliers to perform their work up to a certain pre-approved cost limit.
2.
Execution – Phase 1 (Plumber): Rapid Response Plumbing is dispatched. They arrive, fix the burst pipe, and then submit a “Work Complete” message for their part of the job. This message is a cryptographically signed proof that they have completed their task.
3.
Execution – Phase 2 (Restoration): AquaDry Restoration is dispatched after receiving confirmation that the plumbing work is complete.
They perform the water damage cleanup and repair, and then submit their own “Work Complete” message.
4.
Finalization (CHEIRRS_0): CHEIRRS_0’s system verifies that it has received valid “Work Complete” proofs from both suppliers.
Only when both proofs are received does the system authorize a single, final payment that is split and sent to both Rapid Response Plumbing and AquaDry Restoration.
Why This is a True Three-Party Transaction
•
Interdependency: The restoration work is useless and cannot begin until the plumbing work is complete.
•
Atomic Payment: CHEIRRS_0 will not pay the plumber if the restoration is not also completed, as the job is not finished.
They will not pay the restoration company if the plumber never fixed the leak. The entire event is treated as a single financial transaction that only settles upon full completion by all parties.
•
Shared State: All three parties are operating on a shared, consistent view of the “Emergency Leak Resolution” job status, managed by the underlying ledger.
This scenario provides a clear and practical demonstration of a complex, multi-party transaction that your system is uniquely designed to handle.
___________________________________________________________
___________________________________________________________
An Entire Construction Project
“Colonel, can you imagine how an entire multi-storey construction job might look if multi-party transactions were employed?”
Of course, General. An excellent strategic question. Applying the multi-party transaction model to a full multi-storey construction project elevates it from a simple sequence of tasks to a dynamic, verifiable, and self-executing contract.
Here is how such a project would look.
The Project: “Alpha Tower” – A 20-Storey Commercial Building
Instead of a traditional project plan with linear dependencies and manual payment approvals, we will model the entire construction as a master Business Process Definition (BPD). Each major phase is a “slab” of work, and each slab contains interdependent multi-party transactions.
The Parties (A Sample)
•
The Client: Alpha Corp (the developer)
•
The Architect: “Visionary Designs Inc.”
•
The Structural Engineer: “Bedrock Engineering”
•
The General Contractor: “Summit Construction”
Key Subcontractors:
◦
“DeepDrill Foundations” (Excavation & Foundations)
◦
“SteelFrame Erectors” (Structural Steel)
◦
“GlassCurtain Facades” (Exterior Cladding)
◦
“MEP Solutions” (Mechanical, Electrical, Plumbing)
◦
“Elevators Pty Ltd”
◦
“Finishing Touch Interiors” (Interior Fit-out)
The Multi-Party Transaction Flow
The entire project is a series of nested, event-driven transactions.
Phase 1: The Foundation Slab
1.
Initiation (The “Go-Live” Transaction):
◦
Client (Alpha Corp) initiates the master transaction by lodging the final, approved architectural and engineering plans onto the ledger.
◦
This action automatically triggers the first multi-party transaction: “Slab 0: Foundation”.
◦
The system allocates the budget for this slab from the Client’s account into a project-specific escrow.
2.
Multi-Party Transaction: “Foundation Poured”
◦
This transaction requires three parties to sign off before any payment is released:
a.
DeepDrill Foundations: Submits a “Excavation Complete & Poured” proof, including digital surveyors’ reports and concrete quality certifications.
b.
Bedrock Engineering (The Certifier): Submits a “Foundation Approved” proof, cryptographically signing off that the work matches their engineering specifications.
c.
Summit Construction (The General Contractor): Submits a “Slab 0 Accepted” proof, confirming the work meets their project management requirements.
◦
Atomic Settlement: Only when all three proofs are on the ledger does the system automatically release the pre-agreed payment from escrow to DeepDrill Foundations.
Phase 2: The Structural Slabs (Floors 1-10)
This is where the model demonstrates its power through parallel execution.
1.
Initiation: The successful completion of the “Foundation Poured” transaction automatically triggers the next set of transactions for the structural frame.
2.
Parallel Multi-Party Transactions:
◦
Transaction: “Floor 1 Erected”
▪
SteelFrame Erectors: Submits “Floor 1 Steel Complete” proof.
▪
Bedrock Engineering: Submits “Floor 1 Structural Inspection Passed” proof.
▪
Summit Construction: Submits “Floor 1 Accepted” proof.
▪
Settlement: Payment for Floor 1 is automatically released to SteelFrame Erectors.
◦
Simultaneously, the system can stage the next transaction: While Floor 1 is being erected, the BPD can pre-authorize the transaction for “Floor 2 Erected”.
This transaction, however, has a guard condition: it cannot be executed until the “Floor 1 Erected” transaction is fully settled.
3.
Cascading Execution: This pattern repeats. The moment Floor 1 is settled, the guard on the Floor 2 transaction is met, and SteelFrame Erectors can immediately begin work and submit their proof for the next floor, knowing that the payment is guaranteed by the system the moment their work is certified.
Phase 3: The Facade and Interior Slabs
The system’s event-driven nature prevents common delays.
1.
Event-Driven Initiation: The BPD is configured so that the settlement of “Floor 5 Erected” automatically triggers the “Facade Installation (Floors 1-5)” transaction for GlassCurtain Facades and the “MEP Rough-in (Floors 1-5)” transaction for MEP Solutions.
2.
Inter-Slab Dependencies: The payment for the facade work might depend not only on the architect’s sign-off but also on the successful completion of the structural slabs up to a certain level.
How This Prevents Common Construction Problems
•
Eliminates Payment Disputes: Payments are algorithmic. If the work is certified as complete by all required parties, payment is automatic and immediate. Subcontractors do not need to chase invoices.
•
Prevents “Stuck” Projects: A subcontractor cannot hold the project hostage. If they fail to deliver, the BPD can have a pre-defined “exception” path that automatically notifies the General Contractor to engage a backup subcontractor.
•
Real-Time, Verifiable Auditing: The Client (Alpha Corp) does not need to wait for weekly progress reports. They can see, in real-time on the ledger, that “Floor 12 Erected” has been settled, meaning the steel is up, the engineering is certified, and the payment has been made.
Every step is a verifiable, immutable event. •
Dynamic Resourcing: If SteelFrame Erectors are working faster than expected, the system can automatically pull forward the initiation of subsequent slabs, optimizing the project timeline based on real-world progress, not a static Gantt chart.
In essence, General, the construction site becomes a live, self-orchestrating system governed by a verifiable and immutable set of rules, with payments and progress locked together in a single, atomic flow.
_____________________________________________________________
PREVENTION OF CORRUPTION
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
Of course, General. This is the most critical question. A system that cannot prevent such a catastrophic failure is strategically worthless. The Grenfell Tower disaster was a failure of provenance and verification. The system can prevent a similar tragedy by making it impossible for fraudulent materials to enter the supply chain and be installed without immediate, automated detection.
Here is how it would work.
The Strategy: Cryptographic Provenance and Multi-Party Verification
The core principle is that every component and every action must be cryptographically signed and verified by all relevant parties before it is
considered “valid” on the ledger.
1. The “Digital Twin” and Material Passport
•
This passport is a cryptographically signed token on the ledger that contains:
◦
2. The Multi-Party Installation Transaction
This is where the system becomes a powerful defense. The installation of the cladding is not a simple task; it is a multi-party
transaction called “Install Facade Panel – Sector 7, Floor 12”.
For this transaction to be valid and for payment to be released, it requires cryptographic sign-off from three independent parties:
◦
Their on-site supervisor uses a handheld device. To begin installation, they must scan a QR code or NFC tag on the physical cladding panel.
◦
This action reads the panel’s unique serial number from its digital passport.
◦
The installer’s system then submits a “Proof of Installation” transaction, which includes the serial number of the panel they have just installed.
◦
The site foreman has a separate, independent device. Their job is to verify the work.
◦
They also scan the installed panel. Their device checks the ledger and confirms: “Yes, this panel’s digital passport is valid, its provenance is correct, and it matches the architect’s specification.”
◦
They then submit a “Work Verified” proof to the ledger.
◦
An on-site representative from the architect’s firm performs a final quality assurance check.
◦
They, too, scan the panel. Their system performs the most critical check: it cross-references the panel’s digital passport against the original BPD specification they themselves lodged.
◦
If it matches, they submit the final “Specification Compliant” proof.
How Cheating is Prevented
Let’s imagine scum amongst the subcontractor, “GlassCurtain Facades,” attempts to cheat by installing the cheaper, flammable Chinese cladding.
•
◦
The installer’s device will immediately fail when they try to scan the panel. It has no valid QR code or NFC tag. They cannot create the “Proof of Installation.” The system halts. An alert is raised.
◦
The installer scans the panel and submits their “Proof of Installation.”
◦
The General Contractor’s device scans the panel. It queries the ledger for the passport and finds that the cryptographic signature from the original manufacturer (Reynobond in France) is missing or invalid. The check fails. The system halts. An alert is raised.
◦
Even if a scumbag contractor is complicit and submits a “Work Verified” proof, the system still requires the architect’s sign-off.
The architect’s device will find that the passport, even if it looks legitimate, does not match the original specification they lodged.
The check fails. The system halts. An alert is raised.
◦
What if scum amongst the installer, the contractor, and the architect’s representative on-site all collude? The scumbags all agree to sign off on the fraudulent panel.
◦
This is where ChubbyChecker comes in. The Cross-Check “cc113_immutable-field-overwrite” would run against the transaction.
It would compare the material_spec field from the original BPD with the material_installed field from the “Proof of Installation” transaction.
They would not match.
◦
The check would fail, an evidence package would be broadcast to the entire federation, and the fraudulent activity of the scum would be exposed to all stakeholders in real-time, including the client and regulators.
The End Result
The system makes cheating not just difficult, but computationally and logistically impractical. To succeed, the scum would need to:
The cost and complexity of the fraud would far outweigh the savings from using the cheaper material.
The system doesn’t rely on human trust; it relies on cryptographic certainty and multi-party consensus.
The system doesn’t rely on human trust; it relies on cryptographic certainty and multi-party consensus.
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
Tx-Rails — Built by IT/OT Chain & Cloud Australia (ITOTCCA). Sydney · London.