# Guide: make systemHUB your AI's source of truth (https://systemhub.com/docs/guides/source-of-truth)

> Part of systemHUB Docs · Connect: Settings → AI Gateway in systemHUB · Auth: OAuth (scoping is workspace-level today — see Getting started) · MCP tools: 60 · Full corpus: https://systemhub.com/llms-full.txt

A business does not usually have one copy of a process. It has the SOP, the line in the onboarding email, the slide in the training deck, the paragraph on the website, the answer the support bot gives and the version in someone's head. They agreed once. Then the process changed.

What breaks is not the SOP. The SOP gets updated, because someone owns it. What breaks is **every other place the same fact was repeated**, because nobody owns those, and they are usually the ones a customer actually reads.

This guide is the pattern for making systemHUB the one place a process lives, and for making a change to it reach everywhere else. It is the difference between a library your AI can read and a library your AI can be trusted.

## Why "source of truth" is a workflow, not a setting

Connecting an AI to systemHUB gets you a library it can read. That is layer one, and it is worth having on its own: ask a question, get the answer from your own documented process rather than the model's general knowledge.

But an AI that can only read is a nicer search box. The step that changes how the business runs is the AI **writing the change back**, so the next person and the next agent get the new version without anyone remembering to tell them.

So the loop is:

1. **The process changes** — someone finds a better way, a tool changes, a rule changes.
2. **The AI updates the SOP in systemHUB** — not a copy, not a chat message, the document itself.
3. **The AI sweeps everywhere else that fact appears** and reports what it found.
4. **A human approves what goes out** where it is customer-facing.

Step 3 is the one almost everyone skips, and it is the one this guide is really about.

## 1. Make the document the thing you change

Your AI should treat the systemHUB document as the artefact, not as a reference it consults before writing an answer somewhere else.

```
→ search_content { "query": "refund approval threshold" }
→ get_system_details { "id": "7d4f2a90-…", "fields": ["title","state","owner","document"] }
→ edit_system_content { "id": "7d4f2a90-…", "find": "approved by a manager",
                        "replace": "approved by the finance lead" }
```

Three things make this safe to let an AI do:

- **`edit_*_content` does find-and-replace**, so a one-line correction does not mean resupplying the whole body and risking the rest of it. See [Authoring content](/docs/concepts/authoring-content).
- **Every edit publishes a revision**, so there is a trail. Cut a named version first with `publish_*` before anything substantial — a restore brings back body, Overview, note and tags (see [Document lifecycle](/docs/concepts/document-lifecycle)).
- **The activity log records that an AI did it.** Each event carries `agentCall`, so "what has our AI changed this month?" is answerable. See [Was this an AI or a person?](/docs/guides/auditing-access#was-this-an-ai-or-a-person)

> **Keep the owner in the loop, not in the way.** Every document has a named owner. An agent updating a process it does not own should set the state to ORANGE (`state: 1`, needs review) rather than leaving it GREEN, so the owner sees it needs a look. Never set GREEN from an agent: approval is a human judgement.

## 2. Then sweep everywhere else

This is the part that earns the phrase "source of truth". A fact that is right in systemHUB and wrong in four other places has not been corrected, it has been *contradicted*, and the customer-facing copy usually wins.

**Give your AI the list of places to check.** It cannot guess where your business repeats itself. Write the list down once:

| Surface | Why it drifts |
|---|---|
| **Other systemHUB documents** | The same rule gets restated in a related SOP. `search_content` finds these. |
| **Your public website** | Written once at launch, owned by whoever built the page, reviewed never. |
| **Your help centre / KB** | The highest-risk one, because it also feeds any support bot you run. |
| **Onboarding and lifecycle emails** | Automated years ago, still sending. |
| **Training material and decks** | Signed off, therefore assumed correct. |
| **Your support bot's answers** | Trained or grounded on the surfaces above, so it inherits every error. |

**A worked example, our own.** We publish a fact about which formats systemHUB exports. We got it wrong. Because nothing swept, that one wrong fact reached our FAQ in five places, our pricing page, two knowledge-base articles, our support bot and a sales script used in cancellation conversations. Each of those was a separate small edit by a different person at a different time, all tracing to one unchecked claim. Fixing the original document would have fixed none of them.

The lesson is not "be more careful". It is that **repetition is the failure mode**, so the sweep has to be a step in the process rather than a thing you remember to do.

## 3. Hold a register of the claims you make

A sweep works when there is something to sweep against. The practical form is a short register of the statements your business makes that would hurt if they went stale: prices, limits, guarantees, "we can / cannot do X", turnaround times, formats.

Each entry carries the claim, where it is published, and **when it was last checked against reality**. That last column is the one that does the work. Keep it as a document in systemHUB like anything else, so your AI can read it:

```
→ create_policy {
    "parent": "8c1f4a20-…",
    "title": "Claims Register",
    "description": "Every statement we publish that would cost us if it went stale, where it appears, and when it was last verified.",
    "content": "<p>If we say it publicly and it could change, it belongs here.</p><h3>How to use this</h3><p>Before changing a published claim, check this page for every other place it appears. After verifying one against the product, update its Last checked date.</p><table>…</table>",
    "state": 1
  }
```

Then the standing instruction to your AI is short, and it is the whole guide in one line:

> When a process or a published fact changes: update the systemHUB document, then check the claims register for every other place that fact appears, then tell me what needs changing and what you changed.

**Verify against the product, not against a memory of it.** The cheapest version of this failure is an AI (or a person) confidently restating something they saw once. If a claim is about what the product does, the check is the product: open the screen, call the tool, read the source. A remembered screenshot is not a verification.

## 4. What this gets you

- **A new starter's AI gives the same answer as your best operator**, because it is reading the same document.
- **A process change lands once and propagates**, instead of being half-applied across six surfaces.
- **You can audit it.** `agentCall` on the activity log, plus named versions, means you can see what changed and who or what changed it.
- **Your support bot stops inventing things**, because the material it is grounded on is the material you maintain.

## The checklist

- [ ] One section of systemHUB named as the home for each kind of process, and the AI told which
- [ ] Documents changed in place with `edit_*_content`, not rewritten wholesale
- [ ] An agent's edit to a document it does not own goes to ORANGE for the owner, never GREEN
- [ ] A named version cut before any substantial rewrite
- [ ] The list of surfaces where your business repeats itself, written down
- [ ] A claims register with a "last checked" date per claim, living in systemHUB
- [ ] The sweep is a step in the process, not a thing someone remembers
- [ ] Claims about the product verified against the product, not from memory

Next: **[Publish your AI's skills →](/docs/guides/publishing-ai-skills)** — give the skills your team has built the same visible home.