Keep it good

A shared brain decays the same way a wiki does — unless contributing is easy and accepting is deliberate. That is what review is for.

The queue

Everything an agent proposes waits here with the passage behind it. Settle it in app.nicia.ai, which shows the diff and the source side by side, or over the API:

curl "$API/v1/brains/team:acme/changes?status=staged" \
  -H "authorization: Bearer $NICIA_KEY"

curl -X POST "$API/v1/brains/team:acme/changes/chg_44a1e0/approve" \
  -H "authorization: Bearer $NICIA_KEY" \
  -H "content-type: application/json" \
  -d '{}'

curl -X POST "$API/v1/brains/team:acme/changes/chg_51c8b2/reject" \
  -H "authorization: Bearer $NICIA_KEY" \
  -H "content-type: application/json" \
  -d '{ "reason": "Shipped to staging, not prod" }'

Both settle calls take a JSON body, so send at least {}. On approve, {} settles the whole change; naming records or fields settles part of it.

You are always approving evidence, not an assertion. If a proposal has no passage behind it, that is itself a reason to reject it. See Review for the full model.

Who writes directly

mode sets the policy default, not a per-write override. On an open Brain most writes land immediately; on a reviewed one most agent writes wait, but your own edits and additive schema still land, and destructive changes always wait on both modes. No credential can ask for an exception, because an exception a caller can request is an exception an agent can request. When a service genuinely needs to write straight in while people’s agents are reviewed, give it its own Brain and read across both. See Review.

Let an agent tend it

Planned — ships with the kernel

Not shipped yet.

Nicia’s built-in Brain Agent reads what has landed and proposes maintenance: contradictions between two documents, pages that have gone stale, questions people keep asking that nothing answers.

npx nicia tend team:acme          # or POST /v1/brains/team:acme/tend

Proposed 4 changes:
  · handbook/oncall.md contradicts notes/2026-07-02-oncall-change.md
    on the escalation path
  · 3 documents reference "Project Mercury" — no page defines it
  · handbook/pricing.md last updated 2026-01-14, cited 41 times since

It always proposes and can never write directly. Run it on a schedule and the queue becomes a to-do list for keeping the brain honest.

Standing questions

For the questions your team asks constantly, keep a maintained answer rather than re-deriving it every time. Install the standing-answers schema pack with POST /v1/brains/{id}/schema-packs and { "packId": "standing-answers" }. That one is a console-plane call, not part of the Brain API: it takes the Brain’s platform id — the id field PUT/GET /v1/brains/{handle} returns — rather than the handle, and an organization key with an explicit x-organization-id header rather than a Brain key. Once it is installed, the console’s Pages rail pins a “Standing answers” group above source material, with pending updates routed to Review like any other change.

Planned — ships with the kernel

A dedicated authoring shortcut is not shipped yet: npx nicia standing add and PUT /v1/brains/team:acme/answers/{id} do not exist. Author a standing answer as a typed record against the pack’s kinds instead.

Installing the pack gives you the kinds, not the maintenance. The maintenance agents and the rebuild automation are configured separately — the Brain’s maintained-knowledge panel in the console walks through that setup and reports what is still missing. Once it is complete, Nicia keeps the answer current as the underlying documents change and tells you when the sources behind it move, so a stale answer becomes a review item instead of a wrong answer.

It is your knowledge

Export the whole Brain, any time, in the format you brought it in. One click from the Brain menu in app.nicia.ai (“Export brain”) downloads the .zip directly.

Planned — ships with the kernel

Export is a console operation today. There is no CLI command — npx nicia export team:acme does not exist — and no Brain API operation either: both export paths that exist (the console’s own download, and a bulk export job beside it) sit on the older id-addressed console plane and neither is reachable with a Brain key. Use the console.

You arrived with a folder. You leave with a model.

You get markdown files with your frontmatter intact and the folder structure preserved, plus index.md cataloguing every page, log.md as a greppable activity log, and an AGENTS.md describing the Brain’s own conventions so any agent can pick the export up and work with it. No proprietary format, no lock-in, no support ticket.

That one-click export carries your documents, not your accepted state. The .zip it downloads includes records.json, evidence.json and history.json, but the first two come out empty and history.json carries a single genesis entry per document rather than its revision chain. Typed records, the evidence behind them, every historical version’s bytes, and the real per-document history are what the bulk export job assembles — the same job the aside above names, which has no console button yet. Ask us to run one until it does.

That is the point of the boundary being ours and the knowledge being yours: what leaves is structurally better than what arrived, and it is legible without us.

Next

• Review — the API underneath the queue.
• Receipts — proving what an answer was based on.