How to Maintain AI Compliance Evidence in Connectivity-Constrained Environments

1. The Connectivity Spectrum

Not all deployments are created equal. AI systems operate across a wide range of connectivity profiles, from always-on cloud instances to fully air-gapped classified environments. The SWT3 protocol and its SDKs are designed to produce compliant evidence across the entire spectrum. The key difference is not what evidence is produced, but when it reaches the ledger.

This guide focuses on the intermittent and offline-first profiles. If you are deploying a fully air-gapped system with no network at all, the Self-Hosted Quickstart covers that scenario. For platform-specific edge attestation patterns, see the Edge Attestation Guide.

2. Write-Ahead Log Deep Dive

The write-ahead log (WAL) is the foundation of offline compliance. Every witness operation writes to the WAL before attempting any network call. If the network is unavailable, the evidence is safe on disk. When connectivity returns, the WAL drains.

WAL Format and Location

• Format: JSONL (one JSON object per line, append-only). Human-readable, trivially parseable, no binary dependencies.
• Location: Python and TypeScript: $TMPDIR/swt3-wal/{tenant}.wal. Kotlin: app internal storage.
• Rotation: At 5MB, the old WAL is archived with a timestamp suffix and a new one is started. Archives are retained until explicitly pruned.

Replay Protection

The SDK maintains an in-memory set of recently flushed fingerprints (bounded at 50,000 entries by default). This prevents duplicate anchors after crash recovery. If a process dies mid-flush and restarts, the WAL replays from the last checkpoint, and any fingerprints already successfully submitted are skipped.

Crash Recovery Sequence

• Step 1: Scan WAL from last checkpoint marker forward
• Step 2: Check each payload fingerprint against the replay set
• Step 3: Re-enqueue any unflushed payloads into the active buffer

After a successful flush, the checkpoint marker advances atomically. If the process dies between the flush and the checkpoint update, the worst case is a duplicate submission -- which the server rejects idempotently with no penalty.

Python Configuration

from swt3_ai import Witness

witness = Witness(
    endpoint="https://sovereign.tenova.io",
    api_key="axm_live_...",
    tenant_id="YOUR_TENANT_ID",
    buffer_size=50,           # Larger batches for intermittent
    flush_interval=300,       # 5 minutes between flush attempts
    clearing_level=2,         # Bandwidth-friendly default
)

# Witness operations accumulate in WAL
result = witness.wrap(client).chat.completions.create(...)
# WAL persists to disk immediately
# Buffer drains when connectivity available

TypeScript Configuration

import { Witness } from "@tenova/swt3-ai";

const witness = new Witness({
    endpoint: "https://sovereign.tenova.io",
    apiKey: "axm_live_...",
    tenantId: "YOUR_TENANT_ID",
    bufferSize: 50,
    flushIntervalMs: 300000,
    clearingLevel: 2,
});

3. Buffer Strategy for Unreliable Networks

The buffer layer sits between the WAL and the network. It accumulates payloads from the WAL and attempts to flush them in batches when connectivity is detected. Tuning the buffer correctly is the difference between seamless operation and evidence loss.

Tuning Parameters

Dead-Letter Queue

Payloads that fail after the maximum retry count (default: 5 attempts with exponential backoff) are moved to the dead-letter queue. The default cap is 5,000 payloads. A growing dead-letter queue is the clearest signal that connectivity is degraded beyond what the buffer can absorb. Monitor this metric continuously.

Exponential Backoff

Failed flush attempts back off at 1s, 2s, 4s, 8s, 16s, then cap at 60s between retries. This prevents battery drain and network congestion from repeated failures on mobile and satellite devices. The backoff resets after a successful flush.

Flush Callback

def on_flush(payloads):
    print(f"Flushed {len(payloads)} anchors")
    # Update progress UI, log to local monitoring, etc.

witness = Witness(
    endpoint="https://sovereign.tenova.io",
    api_key="axm_live_...",
    tenant_id="YOUR_TENANT_ID",
    buffer_size=50,
    flush_interval=300,
    on_flush=on_flush,
)

The on_flush callback fires after each successful batch. Use it for progress tracking, local logging, or triggering downstream workflows when evidence reaches the ledger.

4. Batch Upload on Reconnect

When connectivity returns after an extended offline period, the SDK drains accumulated payloads via the batch witness endpoint. This is the most efficient path for large backlogs.

Batch Endpoint

• Endpoint: POST /api/v1/witness/batch (up to 500 payloads per request)
• Ordering: Payloads are sent in timestamp order. The WAL preserves insertion order, so chronological integrity is maintained.
• Idempotency: Fingerprints are unique by construction. Duplicate submissions are rejected server-side with no penalty and no error. This means crash recovery and retries are always safe.
• Partial failure: If a batch partially fails (e.g., 480 of 500 accepted), successful anchors are checkpointed and failed ones are re-queued for the next batch.

Bandwidth Estimates

For satellite connections with per-MB billing, CL2 reduces upload cost by 80% compared to CL0 while preserving all compliance-critical fields. CL3 reduces cost by 90% but hashes the model identifier, which limits some downstream analytics.

5. Clearing Level as Bandwidth Control

Clearing levels were designed for data classification, but they double as bandwidth controls. Higher clearing levels strip more metadata, producing smaller payloads. This is not a workaround -- it is a design feature. Sensitive environments naturally require less data in transit.

6. Offline Verification

SWT3 anchors can be verified without any network connectivity. The verification formula is pure SHA-256 math. No server, no API key, no internet connection required. This is how an auditor in a disconnected location can independently confirm that evidence has not been tampered with.

Python Offline Verification

from swt3_ai import verify_anchor

result = verify_anchor(anchor_token, {
    "tenant_id": "MY_TENANT",
    "procedure_id": "AI-INF.1",
    "factor_a": 1, "factor_b": 1, "factor_c": 0,
    "timestamp_ms": 1774800000000,
})
# result.verified = True if fingerprint matches recomputed value

The verifier recomputes SHA256("WITNESS:{tenant}:{procedure}:{fa}:{fb}:{fc}:{ts_ms}") and compares the first 12 hex characters against the fingerprint embedded in the anchor token. If they match, the anchor is authentic and untampered. This works on any machine with a SHA-256 implementation -- a laptop, a phone, even a Raspberry Pi in a field office.

What Offline Verification Proves

• Integrity: The anchor has not been modified since it was minted
• Binding: The anchor is bound to a specific tenant, procedure, factor values, and timestamp
• Independence: Verification does not depend on the issuing server being reachable

What it does not prove without network access is whether the anchor exists in the central ledger. For full ledger reconciliation, connectivity is required. But for field audits, integrity verification alone is sufficient to establish that evidence was produced at the claimed time with the claimed parameters.

7. Factor Handoff for Custody Transfer

When evidence must physically move between systems -- from a disconnected field device to a connected office machine, or from a satellite-linked station to a ground office -- factor handoff provides the custody chain.

Handoff Workflow

• Step 1 -- Export: Call witness.flush() to write handoff files (one JSON per anchor) to a local directory. Each file contains the full uncleared factor data.
• Step 2 -- Transfer: Copy handoff files via USB drive, approved removable media, or a scheduled file transfer during a connectivity window.
• Step 3 -- Import: The connected machine reads handoff files and posts each to the witness endpoint. The SDK handles batching automatically.
• Step 4 -- Verify: Fingerprints computed on the export machine match fingerprints on the import machine. Any mismatch indicates tampering during transfer.

8. Monitoring Witness Debt

"Witness debt" is the count of unflushed anchors accumulating in the WAL. Like technical debt, witness debt is not inherently bad -- it is expected in intermittent environments. But unmonitored witness debt becomes evidence loss risk.

Alert Thresholds

Reconciliation

Periodically compare the anchor count in the local WAL against the anchor count in the central ledger for the same tenant and time range. Any discrepancy indicates payloads that were lost in transit or stuck in the dead-letter queue. The batch endpoint's idempotency guarantees mean you can safely re-submit the entire WAL contents without creating duplicates.

9. Regulatory Compliance Offline

EU AI Act Article 12 requires record-keeping. GDPR Article 30 requires processing records. Neither provides an exemption for offline systems. The compliance strategy for connectivity-constrained environments is not to avoid these obligations, but to satisfy them through local evidence production with deferred upload.

The Compliance Argument

• WAL is the record. The JSONL file on disk IS the compliance record. It contains timestamps, fingerprints, factor values, and clearing levels. It is machine-readable, append-only, and tamper-evident through sequential fingerprinting.
• Factor handoff is the custody chain. Physical transfer of evidence files creates an auditable chain of custody. Each handoff file is individually verifiable.
• Offline verification is the integrity proof. Any auditor with a SHA-256 implementation can recompute fingerprints without server access.
• Batch upload is the reconciliation. When connectivity returns, the ledger catches up. The timestamps in each anchor prove WHEN the decision was made, not when it was uploaded.

SWT3 Procedures for Offline Compliance

10. Quick Reference

For model-specific evidence requirements when deploying small language models in connectivity-constrained environments, see the SLM Compliance Evidence Guide.

SDK Documentation  |  Self-Hosted Quickstart  |  Create a free account