AURA Core — System Flow Diagrams

Agent Universal Resource Architecture · Protocol v2.2 · April 2026

1. Principal & Agent Registration

Identity via external credentials (DEC-049), agent binding via Ed25519 (DEC-009)

sequenceDiagram
    participant IdP as Identity Provider
    participant P as Principal
    participant Core as AURA Core
    participant DB as Database

    Note over IdP,P: External identity (vLEI, X.509, VI, Open Banking)
    IdP->>P: Issue credential (signed)
    P->>P: Generate Ed25519 key pair

    P->>Core: POST /v1/principals
{credentials, public_key} activate Core Core->>Core: Verify credential signature Core->>Core: Check issuer against Trust Framework Core->>Core: Check expiry & revocation Core->>Core: Map to trust level (L0–L3) Core->>DB: INSERT principal (trust_level, credentials) Core-->>P: {principal_id, trust_level, trust_profile} deactivate Core Note over P,Core: Agent registration (binds to principal) P->>P: Generate agent Ed25519 key pair P->>Core: POST /v1/agents/register
{public_key, principal_id, capacity} activate Core Core->>Core: Validate key + verify signature Core->>Core: Verify principal exists & active Core->>DB: INSERT agent (principal_id, capacity) Core-->>P: {agent_id, principal_id, capacity} deactivate Core Note over IdP,DB: Chain: IdP → Credential → Principal → Agent
DEC-049: AURA is a relying party — it verifies credential integrity, not identity. No DNS challenges, no KYC, no PII storage. Trust levels are credential-derived via the Trust Framework.

2. Request Authentication

Ed25519 signature verification on every protected request

sequenceDiagram
    participant Agent as Agent SDK
    participant Core as AURA Core
    participant DB as Database

    Agent->>Agent: Build request body
    Agent->>Agent: Sign: Ed25519(privateKey,
method + path + timestamp + body) Agent->>Core: HTTP request + headers:
X-Agent-ID, X-Signature, X-Timestamp activate Core Core->>Core: Check timestamp (within 5-min window) Core->>DB: Lookup agent public_key Core->>Core: Verify Ed25519 signature Core->>Core: Set request.agent = {id, status} Core-->>Agent: Response (authenticated context) deactivate Core
No shared secrets. The private key never leaves the agent. The public key is the identity. Every request is independently verifiable. No bearer tokens, no session cookies.

3. Commerce Flow (End-to-End)

Intent → Discovery → Offers → Commitment — the complete agent-mediated transaction

sequenceDiagram
    participant Scout as Scout Agent
    participant Core as AURA Core
    participant Beacon as Beacon Agent

    rect rgba(80, 70, 229, 0.05)
    Note over Scout,Beacon: Phase 1 — Intent
    Scout->>Core: POST /v1/sessions
{intent, constraints, profile_id} Core->>Core: NLP interpretation
+ disclosure projection Core-->>Scout: {session_id, status: collecting_offers} end rect rgba(80, 70, 229, 0.05) Note over Scout,Beacon: Phase 2 — Discovery Beacon->>Core: GET /v1/beacons/sessions (polling) Core-->>Beacon: Interpreted request
(projected, not full intent) Beacon->>Beacon: interpretIntent()
+ catalog matching end rect rgba(80, 70, 229, 0.05) Note over Scout,Beacon: Phase 3 — Offers Beacon->>Core: POST /v1/sessions/:id/offers
{product, price, terms, signature} Core->>Core: CWR ranking
(reputation × compatibility × risk) Core-->>Scout: Ranked offers end rect rgba(80, 70, 229, 0.05) Note over Scout,Beacon: Phase 4 — Commitment Scout->>Core: POST /v1/sessions/:id/commit
{offer_id, authority, consent} Core->>Core: Pre-commitment validation
(6-step gate) Core-->>Beacon: Transaction created Core-->>Scout: {transaction_id, status: committed} end
Privacy by design. Scout identity is abstracted until commitment. Beacons see projected requirements, not full intent. Budget shown as a range. Natural language never forwarded.

4. Session State Machine

22 states across commerce and clearing lifecycles

stateDiagram-v2
    [*] --> created
    created --> collecting_offers: T1: Intent submitted
    collecting_offers --> offers_available: T2: Offers received
    offers_available --> committed: T3: Scout commits
    committed --> risk_assessed: T18: Risk computed
    risk_assessed --> authorized: T19: Margin funded
    authorized --> settling: T20: Instruction sent
    settling --> settled: T21: Proof verified
    settled --> cleared: T22: Reconciled

    committed --> fulfilled: T6: Delivery confirmed
    fulfilled --> completed: T8: All settled

    collecting_offers --> cancelled: T10: Scout cancels
    offers_available --> cancelled: T11: Scout cancels
    offers_available --> expired: T12: Timeout

    committed --> disputed: T13: Dispute filed
    disputed --> resolved: T14: Resolution
    resolved --> completed: T17: Remediation done
    
Phase 7 states: risk_assessed, authorized, settling, settled, cleared (T18–T22). Pre-Phase 7 transactions bypass clearing states. Backward compatible.

5. Clearing Lifecycle (Phase 7)

Post-commitment: risk assessment → authorization → settlement → finalization

flowchart TD
    A[committed] --> B{Pre-Commitment Gate}
    B -->|Business rules| C{Pass?}
    C -->|Fail| Z[403 BUSINESS_RULE_VIOLATION]
    C -->|Pass| D[Consent & authority check]
    D --> E[Settlement compatibility]
    E --> F[Bilateral risk assessment]

    F --> G[risk_assessed]
    G -->|Margin funded| H[authorized]
    H -->|Instruction signed & sent| I[settling]
    I -->|Proof verified ✓| J[settled]
    J -->|Reconciled| K[cleared]

    I -.->|No proof / timeout| L[Exception handling]
    L -.-> I

    style A fill:#f0efff,stroke:#5046e5,color:#1a1a2e
    style G fill:#f0efff,stroke:#5046e5,color:#1a1a2e
    style H fill:#f0efff,stroke:#5046e5,color:#1a1a2e
    style I fill:#fff8f0,stroke:#d97706,color:#1a1a2e
    style J fill:#f0faf0,stroke:#16a34a,color:#1a1a2e
    style K fill:#f0faf0,stroke:#16a34a,color:#1a1a2e
    style Z fill:#fef2f2,stroke:#dc2626,color:#1a1a2e
    
Principle 2.15 — Verifiable Settlement: No proof, no state transition. The clearinghouse advances from settling to settled only when it receives a cryptographically verifiable, non-repudiable proof from the payment rail.

6. Settlement Instruction & Proof Flow

The interface between AURA (market) and payment rails (DEC-045)

sequenceDiagram
    participant CH as Clearinghouse
    participant Adapter as Rail Adapter
    participant Rail as Payment Rail

    CH->>CH: Generate settlement instruction
(Ed25519 signed, idempotent) Note right of CH: Links to L6 commitment hash CH->>Adapter: submit(instruction) Adapter->>Rail: Execute fund movement alt RTP / FedNow Rail-->>Adapter: Irrevocable confirmation (seconds) else Stablecoin Rail-->>Adapter: On-chain confirmation (12 blocks) else Card Rail-->>Adapter: Provisional (120-day chargeback) else ACH Rail-->>Adapter: Provisional (2-day return) end Adapter-->>CH: Proof of settlement
(rail-signed, non-repudiable) CH->>CH: Verify proof (5 checks) Note right of CH: Signature, amount,
correlation, finality, timeliness CH->>CH: settling → settled
DEC-045: AURA defines the market, not the rail. Settlement instructions go out, proof comes back. The cryptographic chain links human intent (L1) through commitment (L6) to fund movement.

7. Market Profile Selection

Protocol parameterization for different market contexts (DEC-044)

flowchart LR
    S[Scout] -->|POST /v1/sessions
profile_id| C[AURA Core] C --> P{Resolve Profile} P --> D1[Participation
6 eval points
7 cost types] P --> D2[Disclosure
5 tiers per field
per phase] P --> D3[Commitment
5 states
profile paths] P --> D4[Risk
margin floors
decay rates] P --> D5[Schema
core + domain
overlays] P --> D6[Identity
trust framework
min trust levels] style S fill:#f0efff,stroke:#5046e5,color:#1a1a2e style C fill:#f0efff,stroke:#5046e5,color:#1a1a2e style P fill:#fafaf8,stroke:#e8e8ed,color:#1a1a2e style D1 fill:#fafaf8,stroke:#e8e8ed,color:#4a4a68 style D2 fill:#fafaf8,stroke:#e8e8ed,color:#4a4a68 style D3 fill:#fafaf8,stroke:#e8e8ed,color:#4a4a68 style D4 fill:#fafaf8,stroke:#e8e8ed,color:#4a4a68 style D5 fill:#fafaf8,stroke:#e8e8ed,color:#4a4a68 style D6 fill:#fafaf8,stroke:#e8e8ed,color:#4a4a68
flowchart LR
    subgraph Retail
        R1[Browse: L0
Commit: L0 < $1K
Clear: L2] end subgraph B2B Trade R2[Browse: L1
Commit: L2
Clear: L3 > $50K] end subgraph Digital Goods R3[Browse: L0
Commit: L0
Clear: L2] end subgraph Services R4[Browse: L0
Commit: L1
Clear: L2] end style Retail fill:#f0efff,stroke:#5046e5 style R1 fill:#f0efff,stroke:#5046e5,color:#1a1a2e style R2 fill:#f8faf8,stroke:#16a34a,color:#1a1a2e style R3 fill:#fff8f0,stroke:#d97706,color:#1a1a2e style R4 fill:#fef2f2,stroke:#dc2626,color:#1a1a2e
DEC-044: Protocol mechanics are invariant. Market parameters are configurable per profile. The FIX analogy: protocol = session layer, profile = venue rules. Default profile reproduces v2.0 behaviour.