Arcform Sovereign Transportier™ — Full Stack Technical Brief

Arcform is the first Sovereign Transportier™ — a neutral, sealed, zero-retention transport layer that carries identity, credentials, proofs, governance signals, and attestations between independent trust ecosystems, while providing deterministic audit evidence without becoming the identity provider, credential issuer, wallet, verifier, or trust authority. It is not an identity provider. It does not store credentials, personal data, or payload content. It routes sealed envelopes between parties and emits trust signals that any party can independently verify.

Core architectural guarantee: Arcform never sees, stores, or processes the content of any envelope. It operates on routing metadata and cryptographic proofs only.

1. ISSUES DIDs           → did:arcform:* identifiers with deterministic keypairs
2. ROUTES ENVELOPES      → DIDComm v2 sealed envelopes via mediator relay network
3. EMITS TRUST SIGNALS   → Deterministic pass/warn/fail verdicts with SHA-256 checksums
4. ENFORCES GOVERNANCE   → Multi-sig council voting with automated enforcement cascades
5. MONITORS COMPLIANCE   → Three circuits: US_flexible, EU_strict, UK_standard
6. PRODUCES AUDIT TRAILS → Every action sealed with proof_checksum, every exchange replayable

Identity & Partner Layer

Transport Layer

Governance Layer

Orchestration & Signals

Plugin & Adaptor Layer

Compliance & Attestation

Trust Mesh & Liquidity

System

Three Send Pathways

Bubble Logic — Ephemeral Message Lifecycle

CREATED  →  FETCHABLE  →  FETCHED  →  EXPIRED  →  STRIPPED
  │              │             │           │           │
  │  send-time   │  recipient  │  24h TTL  │  cleanup  │
  │  envelope    │  fetches    │  window   │  ciphertext│
  │  logged      │  ciphertext │  closes   │  wiped    │

Signal types on ephemeral messages: message (default), proposal, vote, attestation, instruction. Control plane governance signals use proposal/vote/attestation. Priority levels: instruction=2, vote=1, message=0.

XRPL Anchoring (Conditional)

When a linked Xaman wallet exists, sendEnvelope pushes a Payment transaction to the XRPL with the envelope hash, sender, recipient, and timestamp encoded in the Memo field. This is fire-and-forget — the envelope is delivered instantly; the on-chain anchor is a supplementary proof layer. Anchor status tracks: pending → signed → anchored | failed | skipped.

The conductorRun function is the central orchestration engine. Every intent passes through all 8 steps in sequence. The result is a sealed ConductorRun record with a deterministic proof_checksum.

STEP 1: INTENT PARSE
  → Validates intent_action + intent_domain
  → Actions: verify_identity, check_payment, emit_compliance,
             enforce_governance, route_envelope, run_plugin,
             evaluate_trust, bulk_operation
  → Domains: identity, telecom, payments, compliance,
             governance, transport, trust_mesh

STEP 2: CAPABILITY SELECT
  → Auto-selects active plugin matching intent_domain
  → Falls back to pass-through mode if no plugin found
  → Domain-to-plugin-type mapping:
    identity     → hub_access, provider_onboarding
    telecom      → adaptor_activation
    payments     → custom
    compliance   → signal_relay
    governance   → signal_relay
    transport    → extension_binding
    trust_mesh   → custom

STEP 3: GOVERNANCE ENFORCE
  → Queries active GovernanceCouncils
  → Checks for emergency_suspension actions in enforced status
  → If blocked → ConductorRun saved with status: "blocked", returns immediately
  → System actions (is_system_action: true) bypass downstream signals

STEP 4: COMPLIANCE CIRCUIT CHECK
  → Queries FedRAMPMonitoringSignal per circuit
  → circuit="all" checks: EU_strict, UK_standard, US_flexible
  → Looks for signal_value: "healthy" — passes if ≥1 healthy signal exists
  → Advisory when circuit="all"; mandatory for specific circuits

STEP 5: ENVELOPE ROUTING (conditional)
  → Only if intent_domain="transport" or intent_action="route_envelope"
  → Checks FederatedRoute for online routes
  → Skipped for non-transport intents

STEP 6: PLUGIN EXECUTION
  → Calls pluginExecute(plugin_id, action: "execute")
  → Receives step results from bound adaptors
  → Pass-through mode if no plugin selected

STEP 7: TRUST SIGNAL EMISSION
  → Emits AgentSignal with verdict: pass/warn
  → SHA-256 checksum of execution context
  → SKIPPED for system actions (prevents feedback loops)

STEP 8: AUDIT LINEAGE SEALING
  → SHA-256 of full run context → proof_checksum
  → SHA-256 of execution output → execution_output_hash
  → ConductorRun record created with all pipeline results
  → AuditLog entry created

Circuit Breaker

Recursion depth hard-limited at 3. Each chained conductor run shares a trace_id and increments depth. At depth > 3, the run is blocked with governance_reason: "Recursion depth limit exceeded". This prevents feedback loops when governance enforcement triggers downstream conductor runs.

The Compliance/Governance Distinction (Critical for Auditors)

compliance_passed: false  +  governance_allowed: true  +  execution_status: success
= VALID OPERATION

Why?
- Compliance Circuit = Pre-flight check (advisory when circuit="all")
- Governance Layer   = Authoritative ratification (multi-sig, deterministic)
- If governance approves → operation proceeds regardless of compliance advisory
- Compliance becomes mandatory ONLY when a specific jurisdiction circuit is selected

Council Structure

Each GovernanceCouncil has members (with partner_id, DID, jurisdiction, voting_weight), a quorum_threshold (M-of-N), and a quorum_mode.

simple_majority        → Count approve votes ≥ threshold
weighted_majority      → Sum voting_weights of approvals ≥ threshold
unanimous              → All members must approve
jurisdiction_weighted  → Per-jurisdiction weight rules from jurisdiction_rules JSON

Enforcement Cascade (governanceEnforce)

When a CouncilAction reaches status "passed", the automation governanceAutoEnforce triggers governanceEnforce. The enforcement function:

1. Re-validates quorum against live council state
2. Checks member validity (all voters must be current council members)
3. Verifies jurisdiction proposal rights
4. Executes cascade: partner suspension → route isolation → key revocation → evolution signal → recovery action
5. Seals with enforcement_checksum

Enforceable Action Types

Rollback Policy

Each council sets a rollback_policy: no_rollback (permanent), council_vote (requires new vote), auto_expire_30d, auto_expire_90d.

The ComplianceVocabulary entity maps 10 canonical control categories across all three frameworks. Each term maps a FedRAMP NIST control to an eIDAS article to an ISO 27001 Annex A control, with the corresponding Arcform implementation surface.

Plugins are the extensibility layer. Each plugin binds to zero or more APIAdaptors and operates within a compliance circuit scope.

hub_access           → Access control for mesh hub entry points
provider_onboarding  → Automated provider registration pipeline
extension_binding    → Envelope channel extensions (DIDComm v2)
adaptor_activation   → Adaptor health check and activation
signal_relay         → Trust signal forwarding between circuits
custom               → Free-form capability

Plugin lifecycle: draft → installed → active → suspended → decommissioned.

Phase categories: core_trust (Phase 1), ecosystem (Phase 2), sovereign_mesh (Phase 3), marketplace (Phase 4), developer (Phase 5).

The pluginExecute function supports three actions: execute (run bound adaptors + type-specific logic + emit signal), health_check (verify plugin + adaptor health), emit_signal (manual trust signal emission).

fedrampMonitoring (Scheduled)

Aggregates health from TrustZones, TrustEdges, OrchestrationEvents, ContinuumEvents, and AuditLogs. Emits 15 FedRAMPMonitoringSignals per run (5 categories × 3 circuits).

zone_health         → Based on TrustZone signals (healthy/degraded/isolated)
trust_mesh_health   → Based on active TrustEdge count (≥3 = healthy)
orchestration       → Based on recent OrchestrationEvent count (>0 = healthy)
continuum           → Based on recent ContinuumEvent count (>0 = healthy)
compliance          → Based on critical AuditLog count (≤3 = healthy)

AgentSignal

Emitted by TrustAgents and Plugins. Signal types: trust, governance, health, verification, alert, activation, relay. Verdicts: pass, warn, fail. Each signal carries a deterministic SHA-256 proof_checksum and a circuit scope (EU_strict, UK_standard, US_flexible, or all).

attestationBundleGenerate

Aggregates FedRAMP, eIDAS, and ISO 27001 compliance signals plus governance enforcement events into a single CrossJurisdictionBundle with a unified proof_checksum and evolution lineage validation.

complianceHarmonise

Three actions:

• seed_vocabulary — Populates 10 canonical ComplianceVocabulary terms mapping FedRAMP ↔ eIDAS ↔ ISO 27001
• multi_circuit_proof — Generates a single SHA-256 checksum validating all three circuits simultaneously
• regulator_snapshot — Public, no-auth endpoint generating a read-only compliance posture report for a specific jurisdiction (US, EU, UK)

Manifest V3 browser extension providing client-side verification, proof checksum computation, and mesh consensus monitoring.

Zone 1: ACTIVE VERIFICATIONS    → Real-time verification status of recent envelopes
Zone 2: PROOF CHECKSUM ENGINE   → Local SHA-256 computation using Web Crypto API
Zone 3: ALERT PIPELINE          → Polling for governance alerts and compliance events
Zone 4: MESH CONSENSUS PANEL    → P2P mesh node status and consensus coordination

The extension uses the same canonical proof checksum algorithm as the backend — users can independently verify that a checksum computed locally matches the one stored in the audit log.

AI-powered deterministic validation agent. Read-only access to 13 entity types. Responds in English, French, and German.

Entity Access (Read-Only)

Traceability Chain (How the Agent Explains Verdicts)

1. AgentSignal     → signal_id, verdict, circuit, proof_checksum
2. ConductorRun    → governance_allowed, compliance_passed, execution_status
3. CredentialEnvelope / EnvelopeLog → routing details, proof_checksum
4. CouncilAction   → vote tallies, quorum result, enforcement cascade
5. proof_checksum  → The verifiable anchor

Core Transport (6)

Orchestration (3)

Governance (3)

Compliance & Monitoring (5)

Verification & Testing (8)

Verdict Test Suites (4)

Notifications & Email (5)

Tide Events (1)

Infrastructure & Developer Tools (8)

Xaman Wallet Integration (3)

Layouts

• PublicLayout — Landing, docs, plans, status, regulator dashboard, marketplace, use cases
• AppLayout — Authenticated dashboard with sidebar navigation
• DocsLayout — Documentation pages with navigation sidebar

Public Pages (22)

Landing, Login, Register, ForgotPassword, ResetPassword, Plans, Docs (+ 11 doc sub-pages), APIReference, Support, Marketplace, ThankYou, Status, ArcTrust, GetStarted, Terms, Privacy, Changelog, OpenAPI, DeepSeekBrief, ChromeExtension, UseCases, Deck, RegulatorDashboard, ValidationGuide

Portal Pages (24)

PortalDashboard, PortalOnboarding, PortalTestSuite, PortalSandbox, PortalCompliance, PortalWorkingGroups, PortalAdmin, PortalPartnerDetail, PortalProduction, PortalAuditExport, PortalFederation, PortalGovernance, PortalEcosystem, PortalStandards, PortalSovereign, PortalTrustMesh, PortalInstruments, PortalRouting, PortalTrustMarket, PortalLiquidity, PortalOrchestration, PortalContinuum, PortalFedRAMP, PortalRegistry, PortalPlugins, PortalAttestation, PortalHarmonisation, PortalConductor, UserDashboard

Design System

IBM Plex Mono throughout. Dark theme with sovereign-teal (#00C7D9) accent, sovereign-dark (#06080B) background, sovereign-panel (#0C0F14) cards, sovereign-red (#D90429) destructive. Sovereign grid background with scan-line overlay. I18n: English, French, German.

Algorithm: SHA-256 via Web Crypto API (SubtleCrypto)
Output:    Lowercase hex string, 64 characters

Input Fields (in order):
  1. envelope_hash    — String, trimmed, lowercased
  2. sender_did       — String, trimmed, lowercased
  3. recipient_did    — String, trimmed, lowercased
  4. payload_size     — Integer via Math.trunc(Number(x))
  5. timestamp        — String, trimmed (ISO 8601 UTC)

Wire Format (length-prefixed, pipe-delimited, UTF-8):
  "{byte_length}:{value}|{byte_length}:{value}|..."

Example:
  "16:ab0f3e2d1c4b5a6f|44:did:arcform:7d0a...|44:did:arcform:9e1b...|2:51|24:2026-06-30T12:00:00.000Z"

Properties:
  ✓ Deterministic — same input always produces same checksum
  ✓ Content-blind — Arcform never inspects payload data
  ✓ Replayable    — any party can independently verify
  ✓ Length-prefix  — eliminates delimiter ambiguity

The same algorithm is used in sendEnvelope, didcommsSend, arctrust-send, and the Chrome extension's local verification engine.

The ArcTrust portal provides external parties with a testing ground — they can send envelopes from one environment and verify receipt on the other.

1. External party calls arctrust-send with sender_key + recipient_key + message
2. Function resolves both keys via service role (no user session needed)
3. Computes proof_checksum using canonical algorithm
4. Creates EnvelopeLog (audit record — content never stored)
5. Creates EphemeralMessage with Bubble Logic (24h fetch window)
6. Increments sender usage atomically
7. Creates AuditLog entry
8. Returns envelope_id, envelope_hash, routing path, proof_checksum

Both tabs (Arcform + ArcTrust) see the same EnvelopeLog, the same proof_checksum,
and the same AuditLog entry — because they share the same database.

The auditor can:
  - Send from Tab A
  - See the audit record appear in Tab B
  - Compare proof checksums between tabs
  - Download a KDP package for offline verification