You shouldn’t have to trust the word “verified.”
Every AI product now says its output is grounded, verified, on-brand. Those are adjectives. This page is the machinery: what a verified fact is made of, who approved it, and what happens to it when it stops being true. Nothing below asks for faith. Each claim names its mechanism, and the mechanisms are the product.
A record that verified itself with the same AI that filled it in would be circular. That is the failure this design exists to rule out: machines propose, people approve, and both actions are recorded.
What “verified” means
A fact is verified when a person approved it with evidence attached. Until then it waits in an inbox, labeled unverified. The approval itself is recorded: who, when, from what source.
Who does the approving
People. Products and imports can propose facts, and every proposal carries its origin. No machine-proposed fact enters the verified record without a human yes.
What happens when truth changes
Facts age on purpose. Each one carries an expected drift rate, comes up for re-verification on that schedule, and a wrong fact is retired with its history intact - never silently edited.
Start with the question we would ask
Here is the skeptic’s version of our own pitch: “An AI extracted this brand record, and now the same company says it is verified. Verified by whom? The AI that wrote it?” It is the right question, and the answer has to be mechanical, not rhetorical.
So the design separates the two roles completely. Extraction and product write-backs can only propose. Verification is a separate, recorded, human act. The rest of this page is what that separation looks like in the database.
What every verified fact carries
These are columns and triggers on the record’s store, not aspirations. Every fact in the verified record carries all of them.
- the claim
- The statement itself, keyed so the same claim cannot exist twice in the active record. Correcting a fact frees its key for the replacement; it never overwrites in place.
- evidence
- A snapshot of the evidence captured when the fact was proposed - what was detected and where - stored with the fact itself, not linked somewhere and lost.
- source
- Where it came from: a human correction, a citation check, a fidelity check, or the publish firewall. Machine-proposed is labeled machine-proposed, forever.
- approval
- Who proposed it and who approved it, with timestamps. A fact without an approval never leaves the inbox, no matter which product proposed it.
- status
- One life cycle: proposed, confirmed, needs-reconfirmation, superseded, deprecated. Every transition is recorded, so the trail reads like a history, not a current-state snapshot.
- lock
- A load-bearing fact can be pinned so nothing - an operator action or an automated writer - can retire or replace it until a person explicitly unlocks it. The guard is a database trigger, so it binds every writer, not just the polite ones.
- volatility
- An expected drift rate on every fact. Fast-moving truths come up for re-verification sooner than slow ones, instead of one uniform expiry for everything.
The record’s contents have their own page - the group-by-group treatment lives at the record page linked below. This page is only about how entries earn and keep the word verified.
Facts age here. That is the feature.
A verified fact is not verified forever. On its volatility schedule it drops to needs-reconfirmation and queues for a fresh look. A brand record that never doubts itself drifts quietly wrong; this one is built to doubt itself on a timer.
When a fact turns out wrong, the correction path is deliberate: the wrong fact is deprecated - a terminal state that keeps its full history - and the corrected claim is proposed fresh, through the same inbox and the same human approval as everything else. Nothing is edited in place, so an audit can always answer “what did we believe, and when.”
And nothing merges itself. Site extractions, file imports, and every product’s learnings all land as unverified proposals in the inbox. The inbox is not a convenience surface; it is the only door into the verified record.
That is the machinery under one word. The record it maintains is what every Jinn product reads. See your brand read
What “graded” means in the strategy product
The strategy product (Chart) makes a sibling promise: reports graded with receipts. Same rule applies - the word has to cash out in mechanics.
- claim-level check
- Every claim in a generated report is checked against the source it cites - the claim, not just the link. A URL can be live while the sentence citing it is unsupported; that claim still fails.
- fail closed
- An unreadable or errored check counts as unsupported, score zero. A claim never passes the gate by accident, and a broken checker never inflates a grade.
- the gate
- A report ships only when its supported-claim share clears a fixed faithfulness floor. Below the floor, the failing claims go back to the writer instead of out the door.
- the ledger
- Every verdict persists to a claim ledger, so “graded” is auditable after the fact. It is a record you can inspect, not a badge on a landing page.
- regulated claims
- On brands in health, legal, or financial categories, an unsupported claim in a regulated band is dropped entirely and audit-logged. Suppressed, never softened into a hedge.
What we do not claim
We do not claim the record cannot be wrong. A person can approve a bad fact. The claim is narrower and checkable: wrongness here has a short half-life and a complete audit trail - every wrong fact dies deprecated, with its history intact, and its replacement passes the same human gate.
We do not claim every generated word is fact-perfect. We claim the gates that catch failures are deterministic code, disclosed on this site - the record’s approval door here, spend and publish guards on the guardrails page, and the measurement floors on their own page.
Keep going
This page is how entries earn the word verified. The record itself, the models that work on it, the guards around spend, and the measurement floors each have their own page.
- The full tourThe mechanism end to end: how Jinn learns, wears, and works a brand.
- The recordThe 346-signal Brand DNA record, group by group.
- Models & routingWhich model does which job, and the gateway rules underneath.
- Guardrails & spendThe deterministic checks that guard your money and your name.
- Measurement disciplineThe floors our own measurements must clear before we publish them.
Verified, answered
- Can the verified record be wrong?
- Yes - a person can approve a bad fact. What the design guarantees is a short half-life and a full trail: facts re-verify on a volatility schedule, a wrong fact is deprecated with its history intact, and its correction passes the same human approval as everything else.
- Does an AI approve facts into the record?
- No. Products, imports, and extraction can only propose, and every proposal is labeled with its origin. Approval is a separate, recorded human action - who, when, from what source. A fact without one never leaves the inbox.
- What does “deprecated” mean here?
- A terminal exit for a fact that turned out wrong. Deprecating frees the claim’s key so the correction can be proposed fresh through the normal approval door, while the wrong fact keeps its complete history for audit. Nothing is edited in place.
- Is “graded” a badge or a check?
- A check. Every claim in a strategy report is verified against the source it cites, an unreadable check counts as a failure rather than a pass, verdicts persist to an inspectable ledger, and a report below the faithfulness floor goes back to the writer.
Checked, not asserted.
Every mechanism on this page ships in the product, not the pitch. Run the free brand read and watch the first proposals land in an inbox that will not merge them without you.