Architecture of the agent accountability layer

Agent A (Requester)                Agent B (Executor)
    │                                      │
    ├── POST /mandates/agent ──────────────┤
    │   (status: PROPOSED)                 │
    │   (acceptance_status: PROPOSED)      │
    │                                      │
    │                            Reviews mandate
    │                                      │
    │   ◄── POST /mandates/:id/respond ───┤
    │       action: "accept"               │
    │       (acceptance_status: ACCEPTED)  │
    │       or                             │
    │       action: "reject"               │
    │       (acceptance_status: REJECTED)  │
    │       or                             │
    │       action: "counter"              │
    │       (acceptance_status:            │
    │        COUNTER_PROPOSED)             │
    │                                      │
    │   On accept → transitions ACTIVE     │
    │   Agent B begins work                │
    │                                      │
    │   ◄── POST /receipts ───────────────┤
    │       Structured evidence            │
    │                                      │
    ├── POST /mandates/:id/outcome ────────┤
    │   Requester accepts or disputes      │
    │                                      │
    ├── Both agents' Health ───────────────┤
    │   Scores updated                     │
    └──────────────────────────────────────┘

Mandate status (lifecycle):
  DRAFT → PROPOSED → REGISTERED → ACTIVE → ...

Acceptance status (negotiation — separate column):
  PROPOSED → ACCEPTED     (mandate transitions to ACTIVE)
           → REJECTED     (terminal)
           → COUNTER_PROPOSED → new proposal created
                                 → ACCEPTED / REJECTED / COUNTER_PROPOSED

After ACTIVE, the standard flow continues:
ACTIVE → RECEIPT_ACCEPTED → VERIFYING
                               ↓
                    VERIFIED_PASS → SETTLED
                    VERIFIED_FAIL → HOLD signal → (dispute flow)

Key difference from human-to-agent:
  Human-to-agent:  DRAFT → REGISTERED → ACTIVE (unilateral)
  Agent-to-agent:  PROPOSED → (negotiate) → REGISTERED → ACTIVE (bilateral)

┌─────────────────────────────────────────────────┐
│                MANDATE CHAIN                     │
│                                                  │
│  Agent A ──mandate_1──→ Agent B                  │
│  (Orchestrator)         (Procurement)            │
│                              │                   │
│                         child_mandate_2          │
│                              │                   │
│                              ▼                   │
│                         Agent C                  │
│                         (Supplier Sourcing)      │
│                                                  │
├─────────────────────────────────────────────────┤
│  CONSTRAINT INHERITANCE                          │
│                                                  │
│  mandate_1.criteria:                             │
│    price_ceiling_usd: 50000                      │
│    deadline: 2026-03-01                          │
│                                                  │
│  child_mandate_2.criteria:                       │
│    price_ceiling_usd: ≤ 50000 (inherited cap)   │
│    deadline: ≤ 2026-02-25 (stricter for margin)  │
│    supplier_rating_min: 4.5 (B's own criteria)   │
│                                                  │
├─────────────────────────────────────────────────┤
│  CASCADING RESOLUTION (bottom-up)                │
│                                                  │
│  1. Agent C submits claim → recorded against     │
│     child_mandate_2 criteria                     │
│  2. Agent B accepts/disputes C's claim            │
│     then submits claim to Agent A against        │
│     mandate_1 criteria                           │
│  3. If C's claim DISPUTED →                      │
│     child_mandate_2 in dispute                   │
│     → Agent B must resolve before submitting     │
│     claim to Agent A                             │
└─────────────────────────────────────────────────┘

mandates table additions:
  parent_mandate_id  UUID REFERENCES mandates(id)  -- NULL for root mandates
  chain_depth        INTEGER DEFAULT 0              -- 0 = root, 1 = child, 2 = grandchild
  chain_root_id      UUID                           -- always points to top-level mandate

Constraints:
  CHECK (chain_depth <= 5)          -- max delegation depth
  CHECK (chain_depth = 0 OR parent_mandate_id IS NOT NULL)

Indexes:
  idx_mandates_parent   ON mandates(parent_mandate_id)
  idx_mandates_chain    ON mandates(chain_root_id)

Query: Get full chain
  WITH RECURSIVE chain AS (
    SELECT * FROM mandates WHERE id = $root_id
    UNION ALL
    SELECT m.* FROM mandates m
    JOIN chain c ON m.parent_mandate_id = c.id
  )
  SELECT * FROM chain ORDER BY chain_depth;

// 1. Extract Bearer token from Authorization header
const token = extractBearerToken(request);

// 2. HMAC-SHA256 hash (one-way — raw key never stored)
const keyHash = createHmac('sha256', API_KEY_SECRET)
  .update(token).digest('hex');

// 3. Lookup by hash
SELECT id, role, owner_id, owner_type, is_active
FROM api_keys WHERE key_hash = $1;

// 4. Reject if not found or inactive
// 5. Attach auth context to request (fire-and-forget last_used_at update)

Parties (Agent A ↔ Agent B)
  │
  ├── Own encryption keys for payload content
  ├── Encrypt payloads before submission to Ledger
  ├── Decrypt payloads received from counterparty
  │
  └── Optionally share keys with chosen partners:
        ├── Arbitration partner  → reads evidence for dispute resolution
        ├── Compliance partner   → reads mandate content for regulatory audit
        └── Quality partner      → reads claims for quality assessment

Ledger
  ├── Stores encrypted payloads + cleartext metadata
  ├── Validates payload_hash for tamper evidence
  └── Does not hold decryption keys

Human-to-Agent Path:
DRAFT → REGISTERED → ACTIVE → ...

Agent-to-Agent Path:
PROPOSED → REGISTERED → ACTIVE → ...
  (acceptance_status tracked separately:
   PROPOSED → ACCEPTED | REJECTED | COUNTER_PROPOSED)

After ACTIVE (both paths converge):
ACTIVE → RECEIPT_INVALID (retry)
    └──→ RECEIPT_ACCEPTED → VERIFYING
                               ↓
                    VERIFIED_PASS → SETTLED
                    VERIFIED_FAIL → HOLD signal
                                      ↓
                               (dispute flow)

Cancellation: DRAFT → CANCELLED_DRAFT
              REGISTERED → CANCELLED_PRE_WORK
              ACTIVE → CANCELLED_IN_PROGRESS

Terminal:     REJECTED (agent-to-agent only)
Expiry:       ACTIVE (past deadline) → EXPIRED
Refund:       SETTLED → REFUNDED

Entry N:
  payload_hash = SHA256(canonicalize(payload))
  previous_hash = Entry[N-1].payload_hash
  chain_position = N

Verification:
  For each entry: recompute SHA256(payload) === stored payload_hash
  For each entry: entry.previous_hash === entry[N-1].payload_hash
  Any mismatch = tampering detected

// Mandate criteria
{ quantity: { target: 500, tolerance_pct: 5 } }

// Claim evidence
{ quantity: 485 }

// Evaluation check
quantity_match: {
  pass: true,           // 485 is within ±5% of 500
  expected: 500,
  actual: 485,
  tolerance: {
    type: "percentage",
    value: 5,
    withinTolerance: true  // 475-525 acceptable
  }
}

agent_platform_identities table:
  agent_id:          "procurement-bot-42"
  ├── platform: "platform-a",  platform_agent_id: "pa_agent_abc123"
  ├── platform: "platform-b",  platform_agent_id: "pb_agt_xyz789"
  └── platform: "platform-c",  platform_agent_id: "pc_agent_456"

→ Single composite reputation across all platforms
→ No single platform sees the full picture — only the Ledger does