> ## 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. Within an organization, each pending obligation is assigned deterministically to an active member who holds the matching review qualification. The assignment is stable across retries and recovery sweeps, while still distributing different request-and-role pairs across the eligible pool. The five qualifications are `medical`, `legal`, `compliance`, `brand`, and `editorial`. Review qualifications are deliberately separate from workspace permissions. Being an `admin`, `editor`, or `viewer` does not imply medical, legal, compliance, brand, or editorial competence. Organization admins designate qualifications under **Workspace → Team**; reviewers work from **Reviews**. 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. A scheduled recovery sweep repairs missing routes, assigns newly eligible reviewers, and marks overdue work for escalation. Removing a qualification immediately removes and reroutes that member's pending assignments when another qualified reviewer exists. ## 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. Reproducibility and the replay payload are both available in the product from an asset's [dossier](/product/asset-dossier). ## API | Endpoint | Purpose | | ---------------------------------------------- | ----------------------------------------------------------------------------------------- | | `GET /api/approvals` | Review queue | | `GET /api/approvals/{request_id}` | All reviews and rollup state for one asset | | `POST /api/approvals/{request_id}/route` | Derive required reviews | | `GET /api/approvals/{approval_id}/asset` | Content, passport, quality report, and review state | | `PATCH /api/approvals/{approval_id}/assign` | Assign or clear a qualified reviewer | | `POST /api/approvals/{approval_id}/decide` | Approve, request changes, reject, or waive; optionally request claim-level evidence | | `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 | | `GET /api/passport/{content_id}` | The full dossier for one library item: passport, latest validity scan, replay eligibility | The passport is stored on the generation record and returned with generation metadata. `GET /api/passport/{content_id}` is the reader-facing route: it takes the id the Content Library holds, resolves it to the governed generation behind it, and returns the passport with the most recent validity scan attached. Content with no governed generation returns `has_passport: false` and the reason, rather than a partial record. The [Asset Dossier](/product/asset-dossier) is this endpoint rendered. ## 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 qualifications are administrator-declared.** WriterzRoom verifies active membership and the configured qualification; it cannot independently validate a person's professional license or expertise. * **Unstaffed roles remain unassigned.** An owner can act while an obligation has no assignee, but organizations should staff every governed qualification they rely on. * **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. Configure reviewer qualifications and decide assigned work.