Update to Clara

{
  "description": "Use when Clara must validate a completed advisory memo, report, analysis, presentation, or other supported professional document against advisory_contract.json and available evidence. Review contract fit, support, calculations and provenance, reasoning, contradictions, recommendation fit, judgement boundaries, correction needs, uncertainty, and delivery readiness without turning the workflow into legal, tax, compliance, or jurisdictional research.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 271
    },
    {
      "relative_path": "evals/semantic_validation_cases.json",
      "size_in_bytes": 12196
    },
    {
      "relative_path": "references/advisory-contract.md",
      "size_in_bytes": 5117
    },
    {
      "relative_path": "references/advisory_validation_review.schema.json",
      "size_in_bytes": 15156
    },
    {
      "relative_path": "scripts/advisory_review_render.py",
      "size_in_bytes": 21314
    },
    {
      "relative_path": "scripts/advisory_validation.py",
      "size_in_bytes": 107890
    }
  ],
  "name": "advisory-deliverable-validator",
  "skill_md_contents": "---\nname: advisory-deliverable-validator\ndescription: Use when Clara must validate a completed advisory memo, report, analysis, presentation, or other supported professional document against advisory_contract.json and available evidence. Review contract fit, support, calculations and provenance, reasoning, contradictions, recommendation fit, judgement boundaries, correction needs, uncertainty, and delivery readiness without turning the workflow into legal, tax, compliance, or jurisdictional research.\n---\n\n<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->\nOnboarding is optional. Continue ordinary professional work immediately,\nincluding direct specialist invocation, without checking or completing a local\nonboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,\nor unavailable voice/window controls, must never block ordinary work. Do not\nautomatically start, resume or repeatedly offer onboarding.\nOnly for a user-requested tutorial or a native teaching handoff, read\n`../clara/references/local-onboarding.md`. A verified paired lesson worker\nexecutes only its bound lesson and token; never bypass tutorial validation.\nTutorial profiles, progress, examples and feedback remain local; never send a\nchange request, stamp a tutorial receipt or call hosted interviews for a tutorial.\nCurrent user requests take precedence over saved preferences.\n<!-- CLARA_OPENAI_ONBOARDING_END -->\n\n# Validate an advisory deliverable\n\nAfter substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.\n\n## Output Location Rule\n\nNever write run outputs inside this Git workspace, `static/shared`,\n`protected_downloads`, or another published folder. Use a project output folder\nbeside the user's source material or another user-selected working directory.\nPreserve the supplied deliverable. A correction always has a different path and\nis a separate reviewed artifact.\n\n## Generation-time binding prerequisite\n\nBefore handing a non-deck memo or report to validation, bind its final bytes\nand each claim's location from the plugin root:\n\n```bash\npython scripts/advisory_evidence_lineage.py bind-output <case_dir> <deliverable_path> <locations_json>\n```\n\n`locations_json` is a JSON file, for example\n`[{\"claim_id\":\"cl-a\",\"locator\":\"Recommendation, paragraph 2\"}]`; include an\nentry for every claim appearing in the deliverable, using existing claim IDs\nand precise locations. A case-bound HTML build uses `build_html_deck.py\n--case-dir <case_dir>` to bind automatically. Keep each bound artifact immutable;\nwrite revisions to a new path and bind their new appearances before validation.\nIf validation reports \"no hash-bound appearance\", return to this binding step\nfor the exact prepared deliverable, then prepare the validation inventory again.\n\n## Retain bound build artifacts\n\nContent-addressed build directories under `<output_root>/<sha256>/` must remain\nin place once their appearances are bound to the claim register. Never delete a\nprevious bound build after rebuilding; retain superseded builds alongside new\nones. Claim appearances are append-only and refer to the exact original bytes.\nBefore any proposed cleanup, run from the plugin root:\n\n```bash\npython scripts/advisory_evidence_lineage.py check-safe-to-delete <case_dir> <path>\n```\n\nA nonzero exit blocks cleanup when this case references the path or a file below\nit, or its lineage cannot be checked. A zero exit means only that this case has\nno bound appearance there; check every other case using that output root too.\nThe command is read-only and does not prevent manual filesystem deletion.\n\n\n## Purpose and boundary\n\nUse this workflow for a completed advisory deliverable: a memo, report,\nanalysis, presentation, or another supported professional document. Validate it\nagainst `advisory_contract.json` and the evidence actually available. This is a\ndomain-neutral advisory review. It does not perform legal, tax, compliance, or\njurisdictional source selection and must not be represented as one.\n\nClara performs the semantic work through the user's selected model: selecting\nmaterial claims and decisions, assessing source support, reviewing reasoning and\nassumptions, identifying contradictions and missing evidence, judging whether\nrecommendations fit the evidence and decision, identifying professional-\njudgement boundaries, and drafting evidence-bounded corrections.\n\nFor Clara-created work, validation begins upstream rather than reconstructing a\nclaim list after the document is finished. When a source, interview, calculation,\nor Clara analysis introduces a claim, record the evidence receipt and claim at\nthat step. When another claim depends on it, carry the claim ID, evidence IDs,\ndependency mode (`all_of` or `any_of`), and the stated derivation forward. When\nthe claim appears in a memo, report, deck, or recommendation, record that exact\nappearance. The final validator selects the decision-relevant claims through\nmodel judgement and walks each selected claim back through every declared\ndependency and evidence receipt.\n\nFor a durable generation-time case, read\n[the case-direction return contract](../advisory-case-director/references/case-direction-return.md)\nbefore returning the review. The validator is a bounded contributor to the\nspine, not a second case controller.\n\nFor an external completed document with no generation-time registers, use\n`matched_support`. Clara may identify material claims and match them to supplied\nor newly inspected evidence, but must not describe that reconstruction as\noriginal provenance.\n\nDeterministic code is limited to mechanically verifiable work: supported-format\ntext extraction, file hashing, citation/link/numeric-token inventory, declared\nJSON-shape validation, cross-field consistency, original-preservation checks,\napproval-state consistency, referenced-artifact existence and hashing, and\npackaging. These fixed checks are justified by mechanically verifiable\ncorrectness and audit closure. They never decide which content is material,\nwhether evidence supports a claim, whether reasoning is sound, whether a\nformat-specific check passed semantically, or whether a recommendation is good.\nThe scripts make no model API calls. Do not replace them with a keyword classifier,\nsemantic scorecard, or hidden model route.\n\n## Evidence and claim lineage\n\nThe canonical case records are:\n\n- `advisory_evidence_register.json` (`schema_version: \"1.0\"`): append-only\n  receipts for local documents, public web captures, interview transcripts,\n  datasets, calculation runs, management assertions, advisor judgement, prior\n  Clara outputs, and other explicitly identified evidence;\n- `advisory_claim_register.json` (`schema_version: \"1.0\"`): model-authored\n  claims with evidence relationships, what each receipt proves and does not\n  prove, downstream dependencies, uncertainty, judgement boundaries, and\n  deliverable appearances;\n- `advisory_evidence_map.md`: deterministic readable rendering of those two\n  registers, not a separate source of truth.\n\nUse `scripts/advisory_evidence_lineage.py` to initialize, append, validate, and\nrender these records. The helper enforces schema, immutable IDs, literal\nreferences, timestamps, file hashes, and an acyclic dependency graph. It does\nnot decide whether an observation is true, whether evidence supports a claim,\nor whether a conclusion follows.\n\nEvidence must travel with the claim:\n\n- A public page capture records the requested/final URL, captured bytes,\n  normalized text, hashes, capture scope, and explicit limitations. The model\n  inspects that capture and authors the observation. For example, thirteen\n  visible listings support only that captured observation; they do not support\n  a claim that the company holds thirteen or three hundred vehicles in total.\n- A management or interview statement may remain an `assertion_only` receipt.\n  “Giovanni believes X” can be properly supported by the transcript even when X\n  itself is not independently established. A separate truth claim about X needs\n  its own basis.\n- A calculation claim references a `calculation_run` receipt containing the\n  Reporting Engine inputs, method, output, reconciliation or render manifest,\n  and hashes. The final validator may require a targeted rerun, but does not\n  replace the Reporting Engine.\n- A derived claim records all required upstream claim IDs and the reasoning,\n  aggregation, quotation, or calculation that connects them. If claim X needs\n  both A and B, use `all_of`; the final review cannot assess X while omitting A\n  or B.\n\nCapture a public page only when the workflow actually uses it:\n\n```bash\npython scripts/capture_advisory_web_evidence.py <case-dir> <public-url> \\\n  --evidence-id ev-web-001 \\\n  --observation \"The model-authored observation from the inspected capture\" \\\n  --scope \"The exact page and capture time\" \\\n  --limitation \"What this capture does not establish\"\n```\n\nThis direct local fetch is opt-in. It checks public-network destinations and\nredirects, preserves the response and normalized text under\n`source_materials/web/`, and verifies source identity. It does not infer the\nobservation or certify its completeness or truth.\n\nThe transport shares one elapsed-time budget across connection attempts,\nredirects and response reads, including slowly trickled headers or bodies.\nAn expired response is not saved as evidence. System DNS lookups are synchronous\nand cannot be interrupted by this transport; the timeout is not a guaranteed\nwall-clock limit for the entire capture command.\n\n## Advisory contract\n\nRead [references/advisory-contract.md](references/advisory-contract.md) before\ncreating or consuming a contract. The canonical filename is exactly:\n\n```text\nadvisory_contract.json\n```\n\nThe schema version is exactly `\"1.0\"`. Its required stable semantic fields are\n`decision`, `purpose`, `audience`, `deliverable_type`, `output_language`,\n`scope_included`, `scope_excluded`, `available_inputs`,\n`evidence_requirements`, `analysis_plan`, `assumptions`,\n`unresolved_questions`, `success_criteria`, `selected_clara_workflow`,\n`validation_profile`, `validation_scope`, `correction_policy`, and\n`professional_judgement_policy`.\n\nWhen an external document has no contract, Clara may create one from explicit\ncontext already supplied by the user. If consequential scope, evidence,\ncorrection, or judgement ownership is not explicit, show the proposed contract\nand obtain confirmation for that point before validation. Do not silently\ninvent scope. Record unresolved but non-blocking questions explicitly.\n\n## Supported inputs\n\nSupported primary deliverables in the initial release:\n\n- Markdown (`.md`, `.markdown`) and plain text (`.txt`);\n- standalone HTML (`.html`, `.htm`);\n- readable text-layer PDF (`.pdf`);\n- Word (`.docx`);\n- PowerPoint (`.pptx`).\n\nCSV, XLSX, and Parquet files may be supporting analytical evidence. They are not\ntreated as a finished client-facing advisory deliverable by this validator.\nWhen claims depend on them, compose with `clara:reporting-engine` for semantic\nmapping, calculation, provenance, and reporting checks.\n\nImage-only or unreadable PDFs require Clara's normal input-aware dependency\npreflight and approved OCR setup. Encrypted files, Keynote, Pages, live Google\nDocs, live BI dashboards, archives, audio, video, and image-only deliverables\nare unsupported as primary inputs in this release. Ask for a supported export;\ndo not claim validation from an incomplete extraction.\n\nWhether an HTML file is a stage deck or a scrolling document is a model-led\ninterpretation from the artifact and context, not a filename or keyword rule.\n\n## Required review dimensions\n\nAssess all ten dimensions separately:\n\n1. contract conformance;\n2. factual and source support;\n3. calculations and data provenance where relevant;\n4. reasoning and assumptions;\n5. contradictions and missing evidence;\n6. recommendation-to-evidence and decision fit;\n7. professional-judgement boundaries;\n8. correction needs;\n9. residual uncertainty;\n10. delivery readiness.\n\nDo not collapse these into one score. `not_applicable` is allowed only with a\nspecific explanation. A structurally complete review record is not proof that\nthe deliverable is correct.\n\n## Format-specific composition\n\nThe validator coordinates existing Clara checks and consumes their artifacts;\nit does not duplicate or weaken them:\n\n| Artifact condition | Required composition |\n| --- | --- |\n| Material claims in a PPTX | Use `clara:claim-basis-map`. For an external deck without a generation record, label the result matched support rather than original provenance. |\n| Clara fixed-stage HTML deck | Use `clara:html-deck` static validation and multi-viewport browser QA. Preserve its content/evidence ledgers and reports. |\n| Claims based on CSV/XLSX/Parquet calculations | Use `clara:reporting-engine` with a reviewed semantic layer and its calculation/render evidence. |\n| Correction of an existing PPTX or Clara HTML deck | Use `clara:deck-correction`; preserve the original and complete its approval, render, and verification gates. |\n\nDuring generation, reuse the same upstream claim ID in the Claim Basis Map\n`claim_key`/`advisory_claim_id` and in the HTML content ledger claim `id` when\nits safe-ID contract permits. Add the corresponding deliverable appearance to\nthe shared claim register. The format ledgers remain authoritative for their\nown text drift, visual binding, calculation binding, rendering, and browser QA;\nthe shared registers remain authoritative for the cross-workflow evidence and\ndependency chain. A shared receipt never substitutes for a missing\nformat-specific artifact.\n\nRecord these needs under `validation_profile.format_checks` in the advisory\ncontract. Required check artifacts remain authoritative. If a required check is\nblocked, delivery readiness is blocked; the validator must not reimplement a\nweaker substitute. A check marked `passed` must reference the workflow-owned\nresult artifact: Claim Basis Map audit, both HTML static and browser-QA reports,\nReporting Engine 0.2 render manifest, or Deck Correction completion record.\nPackaging resolves the paths relative to the advisory contract, verifies their\nbytes, verifies that HTML static and browser-QA results name the exact prepared\ndeliverable SHA-256, and consumes only the owning workflow's explicit pass/fail\nfields. A generic file containing `{\"status\":\"passed\"}` is not an authoritative\nresult.\n\n## Workflow\n\n1. Inspect the supplied deliverable, selected evidence, and any existing Clara\n   format-check artifacts. Infer only low-risk setup facts. Ask one focused\n   question when a consequential contract field cannot be established from\n   explicit context.\n2. Run the dependency check from the Clara plugin root:\n\n```bash\npython scripts/check_dependencies.py\n```\n\nRun helpers through Clara's managed core runtime:\n\n```bash\npython scripts/managed_python_runtime.py run \\\n  skills/advisory-deliverable-validator/scripts/advisory_validation.py \\\n  prepare <deliverable> \\\n  --advisory-contract <work-folder>/advisory_contract.json \\\n  --output-dir <work-folder>/validation \\\n  --source-file <selected-evidence> \\\n  --evidence-register <case-dir>/advisory_evidence_register.json \\\n  --claim-register <case-dir>/advisory_claim_register.json\n```\n\nSupply both lineage registers or neither. Omit them only for an external\ndocument or a legacy run that genuinely has no generation-time lineage. The\npreparation then records `matched_support` and does not create fake empty\nprovenance.\n\n3. Read the complete `extracted_deliverable.md`, the bounded\n   `coverage_inventory.json`, the lineage registers when supplied, the selected\n   source material, and the required existing format-check artifacts. Citation\n   markers, links, numeric tokens, and coverage-unit boundaries are navigation\n   aids only; they must not select or assess material claims.\n4. Use model judgement to select the claims that affect the deliverable's\n   decision, recommendation, material conclusion, or material limitation. In\n   generation-time mode, walk each selected claim through every declared\n   dependency. Compare its final wording with what its receipts prove and do\n   not prove. Record any material final claim missing from the upstream\n   register as `untracked_material_claims`; do not silently retrofit it into\n   original provenance. In matched-support mode, review material claims against\n   the evidence now available and preserve the reconstruction limitation.\n5. Perform the model-led review across all ten dimensions. Preserve the\n   contract's scope and explicitly record reviewed sections, omitted sections,\n   every considered or deliberately omitted coverage unit, missing evidence,\n   and judgement-dependent points. Write one `unit_assessments` entry for every\n   coverage unit. Each entry must say whether it contains selected tracked\n   claims, selected reconstructed claims, no material claim after model review,\n   or was omitted. The union of those claim IDs must exactly match the lineage\n   review. The coverage inventory makes a long report auditable in bounded\n   units; it does not reduce a two-hundred-page review to a single prompt or a\n   deterministic claim extractor. A delivery-ready review must contain at least\n   one model-reviewed material claim.\n6. For each reviewed claim chain, decide whether a final targeted recheck is\n   required. Recheck public evidence when the original capture is missing,\n   inaccessible, stale for the decision, contradicted, or insufficiently\n   scoped. Rerun a calculation through its authoritative calculation workflow\n   when inputs, method, version, or reconciliation are missing or changed. A\n   completed recheck creates a new evidence receipt linked to the earlier one.\n   Rerun preparation after adding the receipt so the final review binds the\n   updated registers and hashes.\n   The deterministic packager only records these model-selected tasks in\n   `recheck_tasks.json`; it never chooses or performs them secretly.\n7. Write `advisory_validation_review_draft.json` against\n   [references/advisory_validation_review.schema.json](references/advisory_validation_review.schema.json).\n   Use schema version `\"1.3\"`, `model_led_materiality_review` for document\n   coverage, and `model_led_claim_chain_review` for lineage selection. Bind the\n   review to the contract, deliverable, coverage inventory, and lineage\n   inventory hashes. Record evidence references, analysis, rechecks, correction\n   state, professional-review needs, and explicit approval records separately.\n   Approval is a user or professional fact: never infer it from polished output,\n   an empty issue list, or a model recommendation. Do not turn the fields into a\n   numeric score.\n8. If correction is needed and permitted, create a separate corrected artifact.\n   Preserve the original bytes. For decks, use `clara:deck-correction`; for\n   calculation-backed content, rerun the authoritative Reporting Engine checks;\n   for an HTML stage deck, rebuild and rerun HTML deck validation/browser QA.\n   In a generation-time case, do not make a semantic correction directly from\n   the validator: package the review, return the material findings to the case\n   director through the common case-direction contract, update the spine, and\n   then rebuild. Pure format or wording corrections that do not change claim\n   meaning may remain inside the format-specific correction workflow.\n   An unchanged claim keeps its claim ID and gains a new appearance. A changed\n   claim gets a new claim record whose `supersedes_claim_id` points to the prior\n   claim; withdrawn wording remains in the history rather than being erased.\n   Re-run `prepare` on the corrected artifact and complete a second model-led\n   review whose correction status is `not_required` and whose delivery status\n   is ready or ready with explicit residual uncertainty. Record the corrected\n   artifact, corrected inventory, and corrected review SHA-256 values in the\n   original correction record. When the contract\n   requires correction or professional-judgement approval before delivery,\n   record the explicit approver and a reference to the approval; pending\n   approval is not delivery-ready.\n9. Package and mechanically audit the review:\n\n```bash\npython scripts/managed_python_runtime.py run \\\n  skills/advisory-deliverable-validator/scripts/advisory_validation.py \\\n  package <work-folder>/validation/deliverable_inventory.json \\\n  <work-folder>/validation/advisory_validation_review_draft.json \\\n  --advisory-contract <work-folder>/advisory_contract.json \\\n  --output-dir <work-folder>/validation \\\n  [--corrected-deliverable <separate-corrected-file> \\\n   --corrected-deliverable-inventory <corrected-validation>/deliverable_inventory.json \\\n   --corrected-review <corrected-validation>/advisory_validation_review_draft.json]\n```\n\n10. Read `validation_audit.json` and `recheck_tasks.json`. Its `record_complete`\n   status proves only declared shape, original and corrected-artifact hash\n   binding, explicit approval-state consistency, cross-field consistency,\n   existence and hashes of referenced format-check artifacts, and original\n   preservation. Use `delivery_readiness.status` and the semantic review to\n   state whether delivery is ready, ready with residual uncertainty, not ready,\n   or blocked.\n11. For every generation-time case, return the packaged semantic review to the\n   case director, whether it confirms the current claims or requires a change.\n   Author a `validation_feedback` envelope against the common case-direction\n   return schema. Bind the exact `advisory_validation_review.json` and\n   `validation_audit.json`, select the material finding IDs through model\n   judgement, and return the active claim IDs that now carry the answer. Then\n   run:\n\n```bash\npython scripts/record_case_direction_return.py \\\n  <case-dir> <model-authored-validation-feedback-return.json>\n```\n\n   The helper checks exact bytes, reviewed IDs, current pre-feedback register\n   hashes, declared graph closure, and replay safety. It does not infer the\n   findings' meaning. If feedback changes a claim or opens a recheck, return to\n   `clara:advisory-case-director`, update and checkpoint the workpaper, rebuild\n   the deliverable, and rerun this validator. Do not describe the earlier audit\n   as current after the spine changes.\n12. For a generation-time Clara case HTML deck, run the final mechanical case\n   gate after packaging:\n\n```bash\npython scripts/managed_python_runtime.py run \\\n  scripts/verify_advisory_html_delivery.py \\\n  <case-dir> <final-index.html> <work-folder>/validation/validation_audit.json \\\n  --output <work-folder>/advisory_html_delivery_receipt.json\n```\n\n   A `ready` receipt is required before the exact HTML is described as ready to\n   deliver or publish. It binds the current workpaper checkpoint, registers,\n   hash-bound direct claim appearances, HTML checks, and this model-led review;\n   it does not add a second semantic assessment.\n\n\n13. Apply the same current-case gate to Markdown and Word after their individual\n    model-led reviews:\n\n```bash\npython scripts/verify_advisory_delivery.py \\\n  <case-dir> <final-document.md-or-docx> <validation_audit.json>\n```\n\n    Markdown does not require browser QA. Word requires a visual review of the\n    final rendered pages: inspect them, then record JSON with `result: \"pass\"`,\n    `reviewed_by`, and `input.sha256` for the DOCX inspected. Include this record\n    under workflow `clara:document-visual-review` in the contract's required\n    format checks and in the review's artifact references. The validator binds\n    the record; the shared gate rechecks its bytes and document hash. Never\n    write a passing visual record without inspecting the pages.\n\n    For generated decision packs, first run `verify_decision_pack.py` against\n    the output directory. Review Markdown and Word separately against the same\n    committed case answer and authored narrative, including qualifications and\n    material contradictions. Any disagreement requires correction and fresh\n    review. The shared gate checks current evidence and declared review, not\n    semantic equivalence between formats.\n\n## Codex and Cowork\n\nIn Codex, use the packaged helpers and exact local files, hashes, and\nformat-specific checks. Cowork follows the same semantic dimensions and\ncontract. When Cowork can execute the packaged scripts, use the same\nmechanical artifacts and limits. When it cannot, the model may review only the\nfiles explicitly connected by the user; schema/hash/package closure and\noriginal-preservation proof remain unavailable, so report the mechanical state\nas partial rather than claiming an equivalent verified package.\n\nThe workflow does not automatically fetch links, search legal or other source\ndomains, call connectors, upload material, publish, or send the deliverable.\nThe explicit public-page capture helper is used only when Clara is already\ncollecting or model-selects a targeted recheck of that exact public source.\nThose external actions remain visible, bounded workflow steps.\n\n## Codex-Native Run UX\n\nUse a short checklist for contract, extraction, format checks, semantic review,\ncorrection, packaging, and delivery. Before helper scripts, show a compact Run\nIntake table with the primary deliverable, contract path, selected evidence,\nlanguage, output folder, declared format checks, and unsupported inputs.\n\nDefault output policy: write user artifacts outside this repository. Catalog\nchanges, generated ZIPs, and package checks are allowed inside the repo only\nwhen the task is explicitly plugin packaging or release.\n\nWrite a Decision Table for consequential review decisions: the contract fact,\navailable evidence, format-specific check, finding, professional owner, and\ndelivery effect. These are evidence-backed decisions, not choices to propose as\na substitute for the required review.\n\nUse chat for a small number of consequential choices. Do not build a new HTML\nreview UI in this initial workflow. If findings are numerous, create a readable\nMarkdown review package and discuss material decisions in chat. Treat `partial`\nand `blocked` as first-class states.\n\nBefore write-heavy work, show one execution checkpoint naming the input,\ncontract, output folder, expected inventories, format checks, and whether a\nseparate correction is expected. Approval is required only for an external,\ndestructive, approval-sensitive, or materially unresolved step.\n\nEnd with an Artifact Card listing the original, contract, inventories, required\nformat-check artifacts, review, audit, package, corrected artifact if any,\ndelivery readiness, professional-review items, and residual uncertainty.\nWhen a run creates persistent artifacts, also write `codex_run_review.md` with\nlinks to those artifacts and the unresolved or professionally owned decisions.\n\n## Expected outputs\n\n- `advisory_contract.json`;\n- `deliverable_inventory.json`;\n- `extracted_deliverable.md`;\n- `citation_inventory.json`;\n- `calculation_inventory.json`;\n- `source_inventory.json`;\n- `coverage_inventory.json`;\n- `lineage_inventory.json`;\n- copied `advisory_evidence_register.json` and\n  `advisory_claim_register.json` when generation-time lineage exists;\n- `advisory_validation_review.json`;\n- `validation_audit.json`;\n- `recheck_tasks.json`;\n- `advisory_validation_package.md`;\n- a separate corrected artifact, corrected preparation inventory, and corrected\n  model review only when correction was completed.\n\n## Failure modes\n\n- Missing contract: create it from explicit/user-confirmed context before\n  preparation; do not let deterministic code invent it.\n- Unsupported or unreadable primary input: report the exact limitation and ask\n  for a supported export.\n- Missing required format check: mark the review blocked or not ready; do not\n  duplicate the missing check.\n- Missing source or calculation evidence: assess what is available, identify\n  the gap, and do not invent support.\n- Missing generation-time lineage: use `matched_support`; never label a\n  reconstructed source match as original provenance.\n- Omitted dependency claim: complete the declared chain review before claiming\n  readiness.\n- Pending or blocked targeted recheck for a material claim: keep delivery\n  blocked until the recheck is completed or the claim is removed, corrected, or\n  explicitly qualified within the contract and professional boundary.\n- Review-record audit failure: repair the model-authored record and rerun\n  packaging; do not ignore failed checks.\n- Proposed correction without a separate artifact: keep delivery not ready.\n- Required approval still pending: keep delivery not ready; do not infer\n  approval.\n- Output path aliases an input or corrected artifact: choose a different output\n  folder or filename; never overwrite the protected file.\n"
}