Facts

A fact is an assertion your team relies on, lifted out of the document it appeared in so it can be owned, checked, and reused.

Why they are separate

A document is true on the day it is written. A fact is something you keep. Once an assertion is a fact it can have:

• An owner. A person, not the wiki.
• A verification state. Verified, or awaiting verification.
• A freshness date. When it was last confirmed, not when the page was last edited, which is usually a typo fix.

Reviewing

Facts lists what is awaiting verification, which is the queue worth working through. Home surfaces the count so it does not quietly grow.

Verifying is a person saying this still holds. Mari can tell you an assertion is old or that something contradicts it. It cannot tell you the assertion is true.

Decisions

Decisions records what a team chose and why. A decision is a fact with an argument attached, and it is usually the thing new people most need and least often find.

Where facts come from

Facts can be lifted from any ingested document, written directly, or extracted by a scan. Either way the lineage graph keeps the link back to the source, so when the source moves you can see what it touched.

Scanning for facts

Scan facts on the Facts page runs an extraction pass over indexed documents. The configuration dialog decides what it reads and how much model work it is allowed: which sources, an optional query or tag filter, how many documents, and how many claims to lift per document. Every model-backed stage carries a hard budget of calls and tokens. When a budget runs out the scan stops there rather than running up a bill.

A scan can run once, or on a schedule from hourly to weekly. Scheduled scans appear on Scheduled tasks, where the cadence can be changed or paused.

Reviewing what a scan found

Extracted claims do not land in the facts table. They land as candidates attached to the run, each with its claim, evidence, and confidence, and wait for a verdict. Accept or reject each one, with an optional note, and choose whether accepted claims publish as needs-review or verified.

The scan's Review strategy sets how the queue gets worked:

• Human only. No review model calls. Every candidate waits for your verdict, with its embedding evidence alongside.
• AI-guided. A bounded model pass reads the evidence and puts a proposed verdict, confidence, and rationale beside each candidate. You keep the gate.
• Bounded AI. High-confidence proposals are applied within the budgets and instructions you set. Uncertain candidates still wait for you.

Whatever the strategy, the run and every verdict stay on record, so a decision can be read back and reversed. The model flags what looks wrong. It cannot tell you a claim is true, which is why the human-gated modes exist.

Impact before invalidation

Invalidating a fact is not just deleting a row. Other facts and documents may lean on it. Impact on a fact row opens its embedding-space neighborhood: related facts, the evidence behind them, and whether each relation supports, contradicts, or sources the claim. High-impact facts are flagged in the table so the ones worth this look are visible before you touch them. Invalidation preserves the fact's history rather than erasing it.