The API surface

Design rules

• Versioned paths — a breaking change to a shape is a new version, not a surprise
• Every object carries its stable identifier and its tenant scope
• Reads are cacheable with validators; delivery endpoints are designed to sit behind a CDN
• Write endpoints produce proposals or change requests, never direct repository mutations

Resources

The top-level collections.

GET    /v1/sources                     connected repositories and systems
POST   /v1/sources/:id/sync            trigger a synchronization
GET    /v1/content-assets              search and filter the graph
GET    /v1/content-assets/:id          one asset with its bindings
GET    /v1/content-assets/:id/versions the append-only event log
GET    /v1/facts                       source facts
GET    /v1/facts/:id/dependents        content derived from a fact
POST   /v1/proposals                   ask AI for a structured proposal
GET    /v1/changes                     change requests and their state
POST   /v1/changes/:id/publish         publish an approved change
GET    /v1/releases/:number            an immutable content release
GET    /v1/health/findings             content health findings

An AI proposal

What an AI task returns. A proposal is a record, not an applied change — which is the distinction the whole governance model rests on.

{
  "proposal_id": "prop_01J9M4R7TQ",
  "operation":   "rewrite",
  "assets":      ["asset_01J9KQ4M2X"],
  "new_value":   "…",
  "facts_used":  ["FACT-2291", "FACT-2304"],
  "warnings":    ["Audience terminology differs from the brand vocabulary"],
  "provider":    "…",
  "model":       "…",
  "created_at":  "2026-09-21T09:14:22Z"
}

Authentication

• Workspace-scoped API keys with least-privilege roles
• Read-only keys as a first-class role, not a permission you have to remove
• Separate grants for proposal creation and for publishing
• Every call recorded as an event with its actor