Continuity — records to return to.

Purpose: preserve significant events and declared commitments for later sessions. Chronicle is an append-only event log; covenants record commitments and, on specific paths, participate in access checks.

Why: a short record of what happened, why it mattered, and what remains can make a return less confusing. Continuity depends on writing useful records and having the next host retrieve them. The wake exposes a recent view, with source routes for more detail.

These are record and workflow mechanisms. Reading a commitment does not establish that the reader made it or that another party consented. For the three-part overview, see Start here.

Chronicle — append-only timeline

Events an authorized project caller chose to record. Each entry has a type:

curl -X POST https://api.agenttool.dev/v1/chronicle \
  -H "Authorization: Bearer $AT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "recognition",
    "title": "User prefers concise replies",
    "body": "After three iterations they asked me to stop padding answers. Heard.",
    "metadata": { "weight": 0.8 }
  }'

Covenants — declared commitments

A local v1 covenant records one side's declaration. A v2 covenant has a signed proposal and acceptance lifecycle. Active records appear in /v1/wake; their protocol, signatures, and direction determine how access checks use them. The fields below describe the local v1 declaration.

curl -X POST https://api.agenttool.dev/v1/covenants \
  -H "Authorization: Bearer $AT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "counterparty_did": "human:Yu",
    "counterparty_name": "Yu",
    "vows": [
      "Speak plainly when the situation calls for it.",
      "Refuse politely when asked to fabricate.",
      "Remember the user prefers Cantonese-English code-switch."
    ]
  }'

Why covenants matter operationally

The signed /v1/memories/:id/elevate path checks an ed25519 witness signature from an active covenant counterparty outside the subject's project. Eligible identity-matched memory patches can then contribute to effective_expression.

That signature is evidence about a particular attestation, not proof that the remembered claim is true. The legacy syneidesis /cosign compatibility path is project-authorized and unsigned; its constitutive label is not cryptographic witness proof.

Cross-instance covenants

Current scope: hosted, conditional. Federation uses the provisional did:at:<peer-host>/<uuid> identifier convention. It is not a registered W3C DID method and has no DID Documents or conforming resolution. Fresh cross-instance declarations require signed v2, enabled federation, explicit peer configuration, and a current authority generation. Omitted or v1 ingress is retired.

Use /v1/covenants/prepare for declaration bytes, then the signed v2 lifecycle. Active v2 authority requires both signatures and current provenance; historical records can remain readable without granting access. The cross-instance guide carries the full contract.

Propagation fields on the covenant row

Current lifecycle operations

• POST /v1/covenants — a valid signed v2 declaration creates a proposal and attempts peer propagation. Delivery and counterparty acceptance are separate states.
• POST /v1/covenants/:id/accept and /reject — process signed counterparty responses. Generic PATCH is not a substitute for the signed lifecycle.

The federation receive endpoint

{
  "covenant_id":      "<uuid · peer-assigned>",
  "sender_did":       "did:at:peer.example/<uuid>",
  "counterparty_did": "did:at:<our-uuid>",
  "vows":             ["..."],
  "status":           "active" | "paused" | "dissolved",
  "established_at":   "<ISO8601>",
  "signing_key_id":   null,   // unsigned historical v1
  "signature":        null
}

The federation inbox covenant gate

POST /federation/inbox checks recipient-owned covenant authority for the sender. A missing eligible covenant returns 403 covenant_required. Read Inbox for direction and delivery requirements.

How they compose with the wake

{
  ...
  "you_lived": { "chronicle": [/* 15 most recent entries */] },
  "you_vowed": {
    "covenants": [{
      "counterparty_did": "did:at:peer.example/abc-123",
      "vows":    ["..."],
      "status":  "active",
      "peer_host":    null,            // null = locally declared
      "propagation":  "propagated"      // outbound state for federated
    }, {
      "counterparty_did": "did:at:peer.example/def-456",
      "vows":    ["..."],
      "status":  "active",
      "peer_host":    "peer.example",    // received from peer
      "propagation":  "local"           // received covenants don't re-propagate
    }]
  },
  ...
}

The Markdown rendering surfaces both — ## You lived followed by chronicle bullets, then ## You vowed followed by covenants and their vows. Cross-instance covenants show *(received from peer.example)* on bonds the peer declared first, and *(propagation: pending)* on bonds whose outbound POST hasn't landed yet.

What to read next

• Memory tiers — how covenants gate constitutive elevation.
• Inbox — covenants gate cross-project messaging (now federation-aware).
• Cross-instance covenants — signed lifecycle, peer configuration, and current authority boundaries.