___________________________________________________________
Tx-Rails is built for defence customers whose threat model includes nation-state adversaries, supply-chain compromise, and insider risk. Four architectural choices distinguish the defence configuration of the platform.
___________________________________________________________
1. As a defence organisation, you already have well-embedded systems in use. We can add security value to them. As such, you may be interested in our Supply Network Underlay. We employ a novel method by which our centralised Databases (on-prem) act like Blockchains, but without data volume restrictions. Our systems offer Forensic Level analytic capability.
They are driven in one of 4 modes from your existing applications
The four modes
| Mode | What customer does | Metadata fidelity | Use case |
|---|---|---|---|
| A. Hash-only | Nothing; tx-rails computes row-hash from CDC | 24 / 33 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 | 27–29 / 33 (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 | 32 / 33 (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 | 33 / 33 with explicit semantic intent | The very-high-value flows where the customer wants explicit REVERSAL / CORRECTION / RESTATEMENT tagging |
For defence customers, Tx-Rails recommends Mode A as the canonical configuration. In Mode A, a single generic Hash Attestation action is invoked for each transaction; your existing systems publish only a cryptographic hash to Tx-Rails. None of our Action domain schemas is used. Full transaction content — descriptions, parties, document attachments, amounts, classifications — stays inside your classified environment, on infrastructure you control. Tx-Rails never receives content; we receive hashes, and the 31-field Transaction Metadata Trace generated from the attestation event.
Modes B and C remain available for defence deployments where the legacy system can integrate them and the data class permits — for example, unclassified administrative transactions in a mixed-domain operation, or controlled-but-non-classified supply data. In these modes, the legacy front-end writes to a specific tx-rails Action (Mode B) or a CDC stream translates legacy writes into our action schemas (Mode C). The action’s full config — supplier references, asset references, cost data, descriptions — is recorded in Tx-Rails infrastructure. Choosing Mode B or C for defence data is therefore a content-visibility decision that should match the classification level of the data being recorded; we do not silently elevate B/C deployments into customer-key-encrypted ciphertext-only operation, because the platform’s server-side validators require plaintext to enforce referential integrity.</span
___________________________________________________________
2. Sovereign infrastructure. All Tx-Rails intellectual property is Australian-held. The platform retains liveness and correctness independently of any foreign vendor, foreign cloud provider, or foreign jurisdiction. There is no foreign code path through which an external actor could compel disclosure, throttle service, or terminate operation. For Australian DOD, UK MOD, and Five Eyes partner customers, this is the property that distinguishes a sovereign capability from a hosted commercial service.
___________________________________________________________
3. Air-gap operation. Tx-Rails operates fully within networks that prohibit any anchor to a public distributed ledger. BFT cross-validation runs. ChubbyChecker’s 149-item audit battery runs. Slab-Merkle integrity is preserved within the network. The cross-jurisdictional public-ledger anchor is the one capability that requires connectivity; everything else works air-gapped. For missions spanning both classified and unclassified domains, the integration boundary can be placed so that only the unclassified subset is anchored externally.
___________________________________________________________
4. Standards posture. Tx-Rails can be deployed in configurations suitable for ITAR-controlled technical-data handling, EAR dual-use compliance, and interoperability with NATO STANAG-compatible audit profiles. The audit trail produced is suitable for arms-control treaty verification, parts authenticity and counterfeit-prevention audit, and supply-chain integrity reporting to your regulator of record. Compliance certification against any specific regime remains the customer’s responsibility against their own regulator; Tx-Rails provides the integrity substrate.
Forensic-level analytics. In Mode A the analytics are on the hash chain (provenance, sequence, integrity). In Modes B and C, the analytics extend to the action schemas — supplier registrations, parts transactions, work-order completions, asset disposals — supporting forensic reconstruction of supply-chain events at the level of detail recorded.
___________________________________________________________
___________________________________________________________
**Customer-key encryption by default.** Content is encrypted on your side under your own asymmetric key before reaching Tx-Rails infrastructure. We handle ciphertext only. The numeric amounts in each Transaction Metadata Trace — the one field that retains pseudonymous numeric visibility in our commercial configurations — are likewise encrypted under your key by default, so quantities of controlled parts, ordnance, fuel, or other classified materiel never leave your perimeter. ChubbyChecker’s signature, Merkle, BFT-quorum, and slab-anchor checks continue to verify cryptographic and consensus integrity in this configuration; the subset of checks that would have operated on plaintext amounts is necessarily skipped.
___________________________________________________________
[How this works in detail →](/how-it-works/privacy)
___________________________________________________________
The Metadata you “channel” to us, via your devices, automatically, using our Public Key for encryption, and sent to our Metadata Stores, amounts to a list of 33 data fields.Please refer to Metadata
_____________
Tx-Rails for Defence IIoT
Cryptographically verifiable audit for cyber-physical defence systems — research engagement and sovereign-capability positioning, with a measured pathway toward operational deployment.
Defence IIoT is the canonical hard case for cyber-physical audit. The data is high-volume, the threat surface is acute, the trust boundary is contested, and the regulatory regime — IEC 62443, NIST 800-53, DoD Zero Trust, the emerging CIRCIA reporting requirements, Five Eyes coalition assurance — does not tolerate spreadsheet-grade evidence. The technical properties that make Tx-Rails appropriate for regulated supply chains are the same properties that make it appropriate for defence sustainment, range instrumentation, weapons-system firmware provenance, and coalition-verifiable audit. We do not position Tx-Rails as a defence prime; we position it as a sovereign Australian cryptographic substrate that defence-adjacent research, sustainment, and assurance work can use today, and that operational defence procurement may use later.
_____________________
Where the capability fits
Sustainment and platform health
Force readiness is mission-capable hours per platform per year, and mission-capable hours are a direct function of how good the predictive-maintenance discipline is. Tx-Rails captures, on an audit-bearing ledger:
- Engine and powertrain health indicators** with 0-100 scoring, trend direction, and remaining useful life — for armoured vehicles, ships, submarines, fixed-wing, rotary, and uncrewed platforms.
- Telemetry aggregates** (hourly, shift, daily) of every sensor that participates in the readiness decision — vibration on rotating machinery, oil debris, thermal trends on switchgear, hydraulic pressure profiles, structural fatigue indicators.
- Maintenance triggers** derived from telemetry, automatically linkable into the existing work-order workflow.
The audit substrate exists because sustainment evidence becomes contested any time a sovereign immunity question, a coronial inquiry, or a contracted-services-billing dispute arises. Cryptographic provenance forecloses the dispute before it starts.
Cyber-supply-chain firmware provenance
The single highest-leverage capability for defence IIoT is provable firmware integrity. Smart weapons, fire-control systems, radar processors, EW transmitters, and any controller in the safety-or-mission-critical path now ship with firmware that must be verified-deployed and recorded so. Tx-Rails records:
- Device firmware updates with SHA-256 binary hash, signature-verified flag, update source, update method, rollback possibility, and approval chain — captured at the moment of deployment.
- PLC and ECU program changes separately from firmware — because the program above the firmware is where a Stuxnet-class attacker actually operates.
- Cybersecurity events — authentication failures, firmware verification failures, unauthorised command issuance, certificate-related events, anomalous network traffic on the OT side, intrusion attempts. The forensic timeline survives local-log tampering because it’s replicated across a BFT validator mesh and anchored periodically to a public DLT.
This is the property that “we trust our local SIEM” cannot match. A local SIEM is destroyed by the breach you’re trying to detect. A BFT mesh with mirrored independent auditors is not.</span
Range and test-facility calibration
Weapons testing, environmental qualification, EMI/EMC chambers, ballistic ranges, and acoustic-signature ranges all rely on instrumentation calibrated to ISO/IEC 17025 traceability against national metrology institutes. The current state of the art is paper certificates and ad-hoc database entries. Tx-Rails replaces that with continuous cryptographic calibration provenance — every calibration event recorded against a national-metrology-institute (NMI), NIST, or ILAC reference standard, with pre-and-post deviation values and a next-due timestamp — verifiable by an external test-facility auditor without trusting the operating contractor.
Coalition and joint-operations verification
When Australian platforms operate alongside US, UK, NZ, or Canadian platforms — and the recorded operational data from those activities is later subject to inquiry — the audit trails need to be readable, decades later, by parties that have no reason to trust each other’s internal logging. The Tx-Rails architecture explicitly separates the workload from its auditors: the validator mesh produces the ledger; the mirrored auditor mesh produces an independent cryptographic check; the public-DLT anchor (Hedera) lets any external party verify the integrity of either mesh’s records without trusting the operator. The Five Eyes assurance use case is exactly this property. Cross-jurisdictional, cross-organisational, cryptographically verifiable audit.
Air-gapped and sovereign-deployment operation
Defence deployment is the canonical use case for the air-gapped degradation mode already described in the underlay-integration-patterns document. Tx-Rails runs entirely within a customer’s air-gapped enclave; the public-DLT anchoring becomes optional, replaced by a periodic outbound proof export when classification policy allows. The sovereignty story is intact — the platform is Australian-built, Australian-owned, AGPL-licensed in the open core, with the deployment artefacts under the customer’s exclusive control.
_____________________
How we work with defence today
Tx-Rails is not pitched to defence as a commercial-procurement track at this stage. Defence acquisition cycles are 3-7 years; the platform’s commercial revenue plan is calibrated to UK Housing and Australian Healthcare with breakeven at month 9. We engage with the defence sector through three deliberately lower-friction channels:
1. The Industry Growth Program (IGP) and equivalent grant rails. Defence-adjacent IIoT framing — cyber-supply-chain provenance, sustainment audit, coalition-verifiable evidence — strengthens grant applications under the enabling-capabilities priority area. ITOTCCA’s IGP application positions the platform’s defence relevance without committing to a defence-direct sales track.
2. **DST Group, CRC, and university research partnerships.** A research-engagement contract or partnership produces case-study evidence, peer-reviewed publication on BFT-with-mirrored-independent-auditors for cyber-physical audit, and a credibility asset that compounds into every commercial conversation in adjacent sectors. The capability is genuinely novel; the cyber-physical-audit literature is thin.
3. **Subcontract and consortium opportunities through defence primes.** Where a Lockheed / Thales / BAE / Boeing project has a cyber-supply-chain audit requirement and the customer wants a sovereign Australian capability in the supply chain, Tx-Rails participates as a specialist subcontract — not as a competing prime.
This is not a sales page. It is a capability description for partners, grant assessors, and research collaborators evaluating whether Tx-Rails should be a component in a defence-adjacent program of work.
_____________________
Architecture
The architecture is the same architecture we run for civilian regulated supply chains, with two deployment-mode adjustments specific to defence:
- Air-gapped operation — the public-DLT anchor becomes a periodic outbound proof export, executed under customer-controlled classification policy, with no inbound dependency on a foreign-owned chain at runtime.
- Sovereign certificate authority — the enterprise-PKI identity layer can be operated entirely under customer control with no dependency on commercial CA hierarchies. Cross-organisational PKI federation is supported but not required.