The reason your agents can trust Curated Data isn’t the storage or the API. It’s the gate in the middle. Every change passes through a review step before an agent can ever read it. Here’s how that lifecycle works, who can approve, and why one setting is left in your hands on purpose.

Most “knowledge base for AI” tools optimize for getting content in fast. That’s exactly backwards for grounding: an agent that answers from unreviewed content is just hallucinating with extra steps. Curated Data treats approval as the point of the product, not an afterthought.

The lifecycle: draft → in review → approved

Every change to a concept moves through a small, explicit lifecycle:

• Draft. Anyone with edit rights can create or change a concept. It starts as a draft: visible to your team in the workspace, invisible to every agent.
• In review. The author submits the draft for review. It’s now queued for a reviewer, and a document can have at most one revision in review at a time, so there’s never ambiguity about which change is being decided on.
• Approved and live. A reviewer approves it. That document's revision is now immediately available to authorized agents. A reviewer can also reject it with a note, sending it back for revision.

A concept’s rolled-up status reflects where it stands: approved once it has a live approved revision, otherwise in review or draft. Nothing an agent reads skipped this path.

Who can approve

Roles keep the gate meaningful. An editor can draft changes and submit their own work for review. Approving or rejecting requires a reviewer role or above. An editor can propose a change, but can’t bless it into production on their own authority. Every approval is attributed and recorded, so the audit trail always answers “who signed off on this, and when?”

Review isn’t just a yes/no

A revision in review isn’t a black box. Reviewers see the diff against the current approved version and can leave comments on the revision, so “this definition should say 28 days, not 30” becomes a threaded discussion attached to the change itself, not a lost Slack message.

The self-approval setting, and why it’s yours to decide

Here’s a deliberate design choice. A strict reading of “separation of duties” says the author of a change should never be the one to approve it. That’s the right default for a large team. But for a solo founder or a two-person data team, a hard rule against self-approval means nothing ever ships. The only reviewer is also the only author.

So Curated Data exposes allowSelfApproval as an org setting rather than baking in a one-size answer. It defaults on for small orgs (fewer than three members), where a self-review is the difference between shipping and stalling, and you can turn it off the moment you want a second pair of eyes on every change:

{
  "settings": {
    // on for small teams so a solo curator can ship;
    // turn off to require a different reviewer on every change
    "allowSelfApproval": false
  }
}

Why this makes agents trustworthy

The payoff shows up at answer time. Because the API and MCP tools only ever serve approved content, the review gate is the single thing standing between “someone typed this” and “an agent told a customer this.” Write access, even the propose_concept and update_concept MCP tools an agent itself can call, lands as a draft and waits for a human. An agent can help you author knowledge; it can never approve its own.

That’s what lets you hand the system to a security reviewer or an auditor with a straight face: every answer an agent can reach was approved by a named person, the approval is in the log, and the rule that made it so is one you configured, not one you have to take on faith.