> ## Documentation Index > Fetch the complete documentation index at: https://docs.writerzroom.com/llms.txt > Use this file to discover all available pages before exploring further. # Content Governance > Assurance levels, claim-level evidence, executable policy, content passports, validity monitoring, and deterministic replay. Most AI writing tools can draft. The harder question for a regulated team is what happens after the draft: what evidence supports this claim, which rules were checked, who signed off, and is any of that still true six months from now. WriterzRoom records all of it as part of generation, not as a manual step afterwards. Governance records describe **what actually happened in a specific generation**, read back from the pipeline that ran — not what a tier is designed to do. The distinction matters: a run whose editor stage degraded and a run that completed normally belong to the same tier but did not receive the same treatment. ## Where enforcement happens Final enforcement runs **before** publication, on every path: ``` Planner ─┬─ Researcher → Call Writer ─┐ └────────────────────────────► Writer ─┬─ Editor ─┐ └──────────► Formatter ─┬─ SEO ─┐ └───────► Quality Gate ──► Publisher │ └─(one revision pass)─► Writer ``` Quick or Premium, with SEO or without, email-native platform or web — every branch converges on the Quality Gate, and only content that clears it reaches the Publisher. ## Assurance levels Tier membership describes what a tier is *built* to run. It is not evidence about any particular asset. So there are two values, and they are not the same thing. **Declared** — what the tier is designed to run, known before a request exists: | Tier | Declared level | Why | | -------- | -------------- | ---------------------------------------------- | | Quick | `basic` | Skips research and editorial review by default | | Standard | `reviewed` | Always runs research and an editor pass | | Premium | `verified` | Full pipeline | **Achieved** — read back from what actually executed: | Level | Requires | | ---------- | ---------------------------------------------------- | | `basic` | Structural, contract, and compliance checks only | | `reviewed` | Plus an independent editor pass, and the gate passed | | `verified` | Plus research that actually returned sources | When achieved falls below declared — a Premium run whose research returned nothing — the asset is marked `meets_tier_contract: false` and must not be represented as meeting that tier's claim. That is the entire reason the two are computed separately. ## Claim-level evidence Every inline citation gets its own record: the claim sentence, the source, the source's excerpt, when that source was retrieved, when it was published, and a confidence score. ```json theme={"theme":{"light":"github-light","dark":"github-dark"}} { "claim_text": "Roughly forty-one percent of adults check social platforms before rising [1].", "source_title": "Pew: Social Media Use", "source_url": "https://pewresearch.org/...", "source_excerpt": "Roughly forty-one percent of adults report checking social platforms before rising.", "retrieved_at": "2026-08-01T10:00:00+00:00", "published_date": "2026-01-15", "confidence": "high", "entailment": "supported" } ``` Two independent checks run over these: Compares the vocabulary of the claim against the vocabulary of the source excerpt. Catches a citation attached to prose that has nothing to do with its source. Confidence bands are `high`, `moderate`, `low`, and `unsupported`. Term overlap cannot distinguish a claim from its own negation. Consider: > **Source:** "The trial found no statistically significant reduction in mortality (p = 0.31)." > **Claim:** "The trial found a significant reduction in mortality \[1]." Every content word matches. Overlap scores this as high confidence. The claim inverts the source. Semantic verification asks a model to judge each claim against its source excerpt directly, returning `supported`, `not_supported`, `contradicted`, or `unclear`. `unclear` is a real answer — a truncated excerpt often cannot settle the question, and forcing it into a verdict would manufacture confidence the evidence does not carry. ## Executable policy Each vertical declares compliance rules. These are enforced against the finished draft, not merely passed to the model as instructions. | Rule | Behavior | | ---------------------------- | ----------------------------------- | | `mandatory_disclaimers` | Must appear in the output | | `required_citations_minimum` | Minimum verified sources | | `forbidden_claims` | Phrase must not appear — blocking | | `conditional_claims` | Phrase requires supporting evidence | Two details worth knowing: **Negation is not a violation.** "We cannot guarantee any outcome" uses a forbidden phrase in order to deny it. That is a compliance disclaimer, not a compliance breach, and it is not flagged. **Not every condition is machine-checkable.** A rule like *"enterprise-grade" requires specifying certifications* cannot be confirmed by pattern matching — whether the surrounding prose actually specifies certifications takes judgment. Those are reported as **needs manual review** rather than silently passed. An honest "cannot verify automatically" is worth more than a wrong "compliant" on regulated language. ## The content passport Every asset carries a portable production record with a versioned schema: ```json theme={"theme":{"light":"github-light","dark":"github-dark"}} { "schema_version": "1.0", "identity": { "template_id": "...", "template_version": "3.1", "style_profile_version": "3.1.0", "resolved_models": {...}, "source_set_id": "880126590e06d363" }, "assurance": { "declared_level": "verified", "achieved_level": "verified", "meets_tier_contract": true, "components": {...} }, "compliance": { "blocking_violations": [], "advisory_violations": [...], "needs_manual_review": true }, "evidence": { "summary": {...}, "claims": [...], "sources": [...] }, "quality": { "score": 92.0, "passed": true, "issues": [...] }, "review": { "required_approvals": [...], "approvals": [...], "state": {...} } } ``` The passport **computes nothing new**. Every value comes from the stage that had the authority to determine it — a passport that re-derived its own facts could disagree with the pipeline it describes. `resolved_models` records the model that *actually served* each stage, which is not always the one routing selected: if a provider rejects its credentials mid-run, the pipeline reroutes, and the passport records where the work really happened. The source manifest deliberately excludes full source text. A passport records **which** sources were used and enough of each to recognise it — not a copy of the source material. ## Approval orchestration Reviews are routed automatically, from three independent signals: Healthcare routes to medical **and** legal review. Fintech routes to compliance. Legal routes to attorney review. Brand-facing content — campaigns, launches, press releases — routes to brand review. A contradicted claim or an unverifiable conditional claim routes review onto content that would otherwise need none. The third signal is the point. A compliance process keyed only on document type cannot react to what a particular document turned out to say. Reviews are **sequenced**, not just listed: a legal reviewer is not asked to spend time on a document medical review is going to send back. Each carries an SLA, and contradicted claims tighten it. A vertical with no explicit review rule that declares regulated content still routes to compliance review. An omitted rule is an oversight, and a compliance control that can be skipped by forgetting to configure it is not a control. Approvals do **not** block publication today — they are recorded obligations and decisions, surfaced on the asset and in the review queue. ## Validity monitoring A passport is true when issued. It says nothing about a year later. Sources go offline. Regulations move. A 2024 figure stops being current when the 2025 report lands. A scheduled scan re-checks published assets: | Finding | Meaning | | -------------- | ---------------------------------------------------- | | `stale_source` | Published outside the vertical's own recency window | | `dead_link` | Confirmed gone (HTTP 404/410) | | `unreachable` | Could not be checked this pass — deliberately weaker | Staleness is relative to the vertical that generated the content: the same sources are stale for a SaaS piece (6-month window) and perfectly valid for a medical one (36-month window). This reuses the vertical's own freshness setting rather than inventing a second threshold that could disagree with the one generation ran under. Sources with no publication date are never flagged — absence of a date is not evidence of age. And a network timeout is reported as `unreachable`, not as a dead link: one flaky fetch is not evidence a source was retracted. Findings can be acknowledged. Acknowledging does **not** change the status — the asset is still stale; a human has decided that is acceptable. Overwriting the status would erase the finding rather than record the judgment about it. If new problems appear later, the asset resurfaces. ## Deterministic replay Replay answers "could we reproduce this, and how faithfully" before it answers "here is a reproduction." | Fidelity | Meaning | | ------------ | -------------------------------------------------------------------------------- | | `exact` | Every recorded input is still available at the recorded version | | `degraded` | Something moved — a revised template, a rerouted model, updated compliance rules | | `impossible` | The template or style profile is gone; the instructions no longer exist | Drift is reported per field rather than papered over. A replay against a revised template is a re-generation wearing the original's name, and presenting that as a reproduction would be worse than not offering replay at all. Replay returns a request payload rather than running the generation itself, so a replay is metered, rate-limited, and appears in history like any other run. ## API | Endpoint | Purpose | | ---------------------------------------------- | --------------------------------------- | | `GET /api/approvals` | Review queue | | `POST /api/approvals/{request_id}/route` | Derive required reviews | | `POST /api/approvals/{id}/decide` | Record a decision | | `GET /api/validity?needs_attention=true` | Assets needing attention | | `POST /api/validity/{request_id}/scan` | Scan one asset now | | `POST /api/validity/{request_id}/acknowledge` | Accept current findings | | `GET /api/replay/{request_id}/reproducibility` | Can this be reproduced, and how exactly | | `GET /api/replay/{request_id}/request` | The payload that would replay it | | `POST /api/replay/{request_id}/compare` | Diff a replay against the original | The passport itself is stored on the generation record and returned with generation metadata. ## Current limits Stated plainly because a governance feature that overstates itself is worse than one that does not exist. * **Approvals are recorded, not enforced.** Publication does not block on sign-off. * **Reviewer identity is limited.** Cross-user reviewer assignment needs workspace review roles, which are not built yet. * **Semantic verification is opt-in** and runs on Premium by default. It is a model judgment, not a proof. * **Replay is non-deterministic above temperature 0.** Similarity comparison is deliberately coarse to invite human comparison rather than substitute for it. * **Validity monitoring covers source liveness and age.** It does not detect that a regulation changed or that a source was silently edited. Where the Quality Gate sits in the generation flow. How sources are scored before they reach the writer.