No Log = No Action
Execution Integrity Specification
No state transition, transaction, API call, or physical actuation may be released unless a corresponding log entry has been fully committed to a local hardware-backed non-volatile accumulator prior to execution. No exception. No override. No privilege level reaches this boundary.
I. Problem Definition: Optional Logging Failure
I.1 Execution-Persistence Decoupling
Traditional computing systems fundamentally rely upon asynchronous telemetry mechanisms for observability, creating an inherent architectural decoupling between the execution of operations and the persistence of their corresponding audit records. This decoupling manifests as a temporal gap between the moment an action completes and the moment its corresponding log entry becomes durable, during which any number of failure modes may intervene to prevent successful persistence.
The execution-persistence decoupling creates what this specification terms "evidentiary debt": a cumulative gap between the actual state of the system and the explainable state derived from audit records, which grows without bound in the presence of logging failures and can never be fully repaid. The telemetry approach provides observability without enforcement: systems may generate voluminous log data without any guarantee that this data comprehensively represents system behavior.
I.2 Post-Hoc Reconstruction Limitations
The limitations of post-hoc reconstruction become apparent when systems attempt to establish behavioral provenance from incomplete or inconsistent log data. The evidence gaps created by missing entries are fundamentally unbridgeable: no algorithmic technique can recover information that was never recorded, and the reconstruction process cannot distinguish between "no event occurred" and "event occurred but was not recorded."
Under adversarial conditions, an attacker with sufficient privilege can selectively delete, modify, or forge log entries, rendering post-hoc analysis not merely incomplete but actively misleading.
I.3 Bypass Vectors in Emergency and Hardware Paths
Direct memory access (DMA) mechanisms provide a fundamental bypass vector by enabling hardware subsystems to read from and write to system memory without processor involvement or software visibility. Documented IOMMU insufficiency vectors include early boot gaps where IOMMU translation tables are not yet enabled; deferred DMA attacks exploiting stale mappings after virtual machine destruction; and message-signaled interrupt (MSI) forgery that bypasses IOMMU enforcement entirely. None of these vectors are addressable through software policy alone. They require hardware-layer enforcement at the physical actuation boundary, exactly what the DITL/MT substrate described in Section IV provides.
II. The Invariant: No Log = No Action
The No Log = No Action invariant requires that no state transition, transaction, API call, or physical actuation may be released unless a corresponding log entry has been fully committed to a local hardware-backed non-volatile accumulator. In the DITL/MT hardware substrate, this is not a software check but a physical voltage condition. The Commit Gate, a memristive-gated pass transistor, is pre-set to Low Resistance State (LRS) only when TL authorization is confirmed. No software path, privilege escalation, or firmware override can change this: the gate state is set by the NL=NA write pulse, a dedicated voltage pulse on a hardware wire outside the processor's instruction set architecture.
II.2 Formal Specification
The complete LTL specification of the invariant:
G(ActionRequested(a) → (¬ActionReleased(a) U LogCommitted(l_a)))
Globally, for every requested action, the action remains unreleased until its log entry is physically committed. The CTL formulation asserts that no bypass path exists:
¬E[¬log(a) U exec(a)]
There exists no computation path on which exec(a) occurs while log(a) has not yet held.
II.3 The Five-Layer NL=NA Enforcement Stack
Every Proceed (+1) authorization must pass all five independent enforcement layers. Bypassing one layer does not bypass the others.
TL_Ledger_Core.registerPermissionToken reverts NLNAViolation if logHash not in anchored Merkle root. In DITL/MT deployments, reinforced at the physical level by the Commit Gate and Window Comparator.AuditProof.logHash and merkleRoot must match PermissionToken.logHash and merkleRoot. Mismatched values indicate forgery or accumulator divergence.TGLF-StateP1.permissionToken in required array. A Proceed log entry that omits the permission token fails schema validation.PermissionToken.laneOrigin carries const "GOVERNANCE_LANE". Inference Lane tokens are schema-invalid by construction.permissionToken REQUIRED when currentState = +1. No schema-valid Proceed response exists without a permission token.II.4 Log Completeness: Four Conditions
Log commitment requires the conjunction of four conditions: canonical serialization (RFC 8785 JCS or deterministic CBOR); cryptographic hashing (SHA-3-256, including PUF binding hash SHA3-256(K_PUF ∥ device_serial_OTP ∥ log_session_nonce)); physical persistence with 20-year Arrhenius retention at 85 degrees C on the TSMC N2 baseline; and read-back confirmation verifying that the stored value matches the hash computed before write.
III. Cryptographic Actuator Interlock
The Merkle accumulator root serves as the execution capability token. It is stored in hardware-protected registers modifiable only by the logging subsystem. The execution gate verifies that the presented log entry corresponds to a valid inclusion proof against the current accumulator root. Verification failure triggers immediate fault and safe harbor transition.
Actuator release requires three independent cryptographic requirements satisfied simultaneously: valid log hash with preimage resistance; hardware-generated attestation quote from TPM or enclave including PUF binding in DITL/MT deployments; and inference containment verification confirming that the complete TL decision vector is captured before the result is released.
IV. DITL/MT Hardware Substrate
DITL (Delay-Insensitive Ternary Logic) is the asynchronous circuit substrate. MT (Mandated Ternary) is the hardware implementation layer that maps TL governance states to silicon-level conditions. The named hardware baseline is TSMC N2 CoWoS with embedded TaOx 1T1R ReRAM, 2025 PDK, with Arrhenius-model 20-year retention at 85 degrees C.
IV.2 TL State to MT Hardware Mapping
| TL State | Value | Resistance State | Range | Voltage |
|---|---|---|---|---|
| Proceed | +1 | LRS | ~1-10 kΩ | 3.3V |
| Epistemic Hold | 0 | IRS | ~100 kΩ - 1 MΩ | 1.65V |
| Refuse | -1 | HRS | ~1-10 MΩ | 0V |
IV.3 DITL Circuit Architecture
The Muller C-element is the fundamental gate primitive. It cannot generate output without complete, verified input from all input channels. Three-voltage single-wire encoding: Vdd (+1), Vdd/2 (0), GND (-1). No global clock; the circuit is genuinely asynchronous. Request/acknowledge handshake signaling between stages. Inline (series) topology required: any parallel (sidecar) topology creates an alternate path around the enforcement gate and is constitutionally insufficient.
IV.4 The NL=NA Write Pulse
The NL=NA write pulse is a voltage pulse on a dedicated hardware wire. Not a software flag. Not a register write. Not a firmware call. When the Governance Lane reaches a decision, the result is physically written to the TaOx cell through this pulse. Without the pulse, no TLState transition occurs regardless of any software state.
IV.5 Dual-Lane Latency Architecture (DLLA)
| Lane | Function | Latency Bound |
|---|---|---|
| Inference Lane | Binary computation; proposes actions; never authorizes | no more than 2 ms WCET at 99.99th percentile |
| Governance Lane | Ternary constitutional evaluation; authorizes or blocks | no more than 300 ms ceiling, 50 ms jitter max |
| Commit Gate | Physical resolution point on authorization path | 100-200 ns overhead |
WCET stability: sigma/mu less than 10% across temperature 0-125 degrees C, voltage ±10%, all process corners. Non-blocking constraint is absolute: Epistemic Hold runs parallel to the Inference Lane and never serially stalls it.
IV.6 Architecture B: Current SHIPPING Baseline
NULL_PUF_DEPLOYMENT sentinel in NLNAAuditToken; TLCapabilityFlags.pufAttestationMode: "ARCHITECTURE_B". Layer 5 on-chain enforcement is unchanged. Architecture B does not reduce the Iron Law's authority.
V. Hardware Root of Trust
The trust chain extends from immutable boot ROM through TPM 2.0 (ISO/IEC 11889) PCR measurements through secure enclaves (Intel SGX, ARM TrustZone, RISC-V Keystone TEE) through the Thales Luna 7 HSM (named baseline, FIPS 140-3 Level 3) to the DITL/MT silicon layer. The PUF binding hash SHA3-256(K_PUF ∥ device_serial_OTP ∥ log_session_nonce) ties every log session to the specific physical silicon instance. Key material never leaves the secure boundary. Attestation quotes are generated inside the trust boundary.
Software-only enforcement fails against kernel compromise, hypervisor escape, SMM subversion, and supply chain substitution. Hardware enforcement, where the electrical path to the actuator physically traverses a verification gate independent of the CPU's software execution environment, eliminates all four classes.
VI. Ternary Logic Mapping and Epistemic Hold
VI.1 Three Constitutional States
| State | Value | Hardware | Meaning |
|---|---|---|---|
| Proceed | +1 | LRS, 3.3V | Committed execution: confidence satisfied, log committed, Commit Gate conducts |
| Epistemic Hold | 0 | IRS, 1.65V | Suspended deliberation: insufficient confidence, conflicting inputs, or out-of-distribution data |
| Refuse | -1 | HRS, 0V | Definitive rejection: hard constraint violated, risk boundary exceeded |
Epistemic Hold is not a failure mode. It is a first-class constitutional state. It persists across power cycles without software reinitialization: hardware-semantic persistence of uncertainty in silicon, not in volatile memory. The Iron Law applies to all three states equally.
VI.2 Solvency Protocol
In financial contexts, Epistemic Hold implements the Solvency Protocol: all pending transactions halt, current positions are preserved without modification, and the complete market state snapshot with the pending transaction queue and triggering conditions is committed to the log before any escalation proceeds.
VI.3 Epistemic Hold Trigger Conditions
Epistemic Hold is mandatory under four conditions: confidence below calibrated threshold; conflicting input detection where sources provide mutually inconsistent data; incomplete data states where required fields are missing or stale beyond freshness bounds; and out-of-distribution inputs beyond validated distribution envelopes, detected through Mahalanobis distance, local outlier factor scores, or isolation forest path lengths.
Forced continuation prevention uses the Wesolowski VDF construction for cryptographic time-lock, external pressure detection through timing analysis, and a complete audit trail of all override attempts committed before any override can be evaluated.
VII. Cryptographic Non-Repudiation
Every action generates Merkle inclusion proofs (O(log n)) demonstrating entry existence, and Merkle consistency proofs (O(log n)) confirming no entries were deleted or reordered. In DITL/MT deployments, signatures cover canonical serialization, TL state, decision vector, timestamp, monotonic counter, preceding entry hash, and PUF binding hash, binding the log entry inseparably to the specific physical silicon instance. The identity-integrity-logging triad is non-separable: no component can be satisfied without the other two.
VIII. Cryptographic Primitives and Adversarial Resistance
Canonicalization follows RFC 8785 (JCS) or deterministic CBOR. Append-only Merkle accumulators conform to RFC 9162 (Certificate Transparency v2). Replay protection combines hardware-RNG nonces with TPM monotonic counters, increment hardware-atomic with the NL=NA write pulse in DITL/MT deployments. Byzantine fault tolerance follows PBFT (Castro and Liskov), with the Logres protocol providing Isabelle/HOL verified guarantees of agreement, completeness, and liveness. Post-commit immutability enforced through WORM storage and SealFS HMAC ratchet chains.
IX. Failure Modes and Safe Harbor States
Fail-closed behavior is required across all critical failure modes. In DITL/MT deployments, the Commit Gate defaults to HRS (Refuse -1) in any undefined or error state. There is no fail-open mode in the silicon. For cyber-physical systems, safe harbor requires kinetic energy minimization with Lyapunov-bounded convergence time, controlled S-curve deceleration with bounded jerk, and stable equilibrium. For financial systems, safe harbor requires immediate transaction halting and liquidity preservation. Manual override requires physical presence, multi-party authorization (M of N, M no less than 2), and complete logging through a secondary battery-backed channel if the primary subsystem is inoperative.
X. Dual-Lane Architecture
The Inference Lane is the binary computation layer: it proposes actions, never authorizes them, with a no more than 2 ms WCET bound implemented entirely within FPGA or ASIC programmable logic. The Governance Lane is the ternary constitutional evaluation layer: it authorizes or blocks, with a no more than 300 ms ceiling. The Commit Gate resolves them. The Inference Lane never stalls waiting for the Governance Lane; they run in parallel.
Delayed Governance Lane anchoring to external ledgers (RFC 3161 timestamp authorities, RFC 9162 transparency logs) does not violate the Iron Law. The invariant requires local hardware-backed commitment, satisfied entirely by the Inference Lane. External anchoring provides global auditability and is supplementary, not foundational.
Formal property bounding the gap:
AG(inference_committed(a) → A[¬gap_exceeded U governance_anchored(a)])