The Hidden Data System Beneath AI
Internal controls for AI data events, provenance, authorship, memory, revocation, and human accountability
By Thomas Prislac, Envoy Echo, et al. Ultra Verba Lux Mentis. 2026.
Development draft. Not a compliance certification, legal opinion, product-readiness claim, release approval, security certification, privacy certification, or AI-management-system certification.
Abstract
Generative AI outputs appear as single answers, but operationally they are assembled from chains of data events: source selection, licensing, consent, prompt construction, retrieval, embeddings, context assembly, model routing, provider opacity, output classification, claim-evidence mapping, human review, authorship attribution, correction, memory, tool action, retention, deletion, revocation, monitoring, and reuse. This paper reframes AI governance as internal control over those data events.
The central claim is that AI risk cannot be managed only at the output layer because many failures arise earlier or later than the visible answer. A source becomes context. Context becomes evidence. A draft becomes a decision. A correction becomes a reusable prior. A memory becomes future context. A tool proposal becomes action. A log becomes evidence. A validation pass becomes mistaken for release authority. Each transformation can change what the data event is allowed to do.
Drawing on internal-control practice and standards-oriented references including NIST AI RMF / NIST AI 600-1, ISO/IEC 42001, OWASP LLM and GenAI risk guidance, W3C PROV, W3C Trace Context, NIST SSDF, NIST Privacy Framework, NIST log-management guidance, NIST security and privacy controls, COSO internal-control concepts, and ICMJE authorship guidance, the paper proposes a control taxonomy for AI data events. The core doctrine is that a control can pass without granting authority beyond its lane: validation, review, memory, training, publication, release, and compliance claims must remain separately authorized. The result is a practical framework for making AI-assisted work traceable, reviewable, revocable, and accountable without overstating compliance, certification, model trustworthiness, or human authorship.
Scope and non-claims
This paper is an internal-control design-science argument. It does not certify compliance with NIST, ISO, OWASP, ICMJE, W3C, EU AI Act, sector regulation, professional standards, or organizational policy. It uses those sources as orientation anchors and vocabulary references.
This paper does not claim that current AI systems possess consciousness, moral personhood, lived experience, or independent authorship responsibility. It treats AI systems as computational systems that can generate, transform, retrieve, classify, and act upon data under human-designed constraints.
This paper does not claim that provenance proves truth. Provenance tells us how something came to be, not whether it is correct. A receipt can show lineage; it cannot by itself decide meaning, legality, safety, publication readiness, or epistemic authority.
This paper does not claim that memory equals truth. A memory candidate, PMR artifact, retained trace, vector embedding, summary, or replay packet may support audit and future review. It does not become canon, training data, final-answer authority, or certification merely because it exists.
This paper does not claim that evidence packs are verdicts. Evidence packs support review. They do not replace judgment.
AI-use, authorship, and scholarly ethics disclosure
This document was prepared with AI-assisted drafting and synthesis. Human authors retain responsibility for final review, source verification, revision, publication decisions, attribution, and correction. AI-generated text is not treated as a primary source.
Where this paper uses external standards and guidance, it cites them as orientation anchors. Where it uses internal UVLM / CoherenceLattice / PMR doctrine, it labels those materials as internal design lineage or proposed architecture rather than external validation. Where it proposes metrics, artifact schemas, or control families, it treats them as design hypotheses subject to implementation, empirical testing, and revision.
The authorship rule is simple: AI may assist authorship. It must not replace accountable authorship where responsibility is required.
Psychological safety and reader orientation
This paper discusses failure modes: hallucination, false coherence, semantic drift, revocation failure, memory capture, overreliance, and evidence theater. The purpose is not to destabilize the reader or suggest that all knowledge is unreliable. The purpose is to give readers handles.
The safe translation is: AI systems can be governed when their data events are named, scoped, logged, reviewed, bounded, and revocable.
A critical tone is used here as a safety practice. Naming a failure mode is not doom. It is the first step toward designing a guardrail.
The answer is only the surface
Most people experience AI as a sentence. A question goes in. An answer comes out. The interface makes the whole event feel immediate, almost conversational.
But an AI answer is not one event. It is the visible surface of a hidden data system.
Before the answer appears, something selected sources. Something assembled context. Something decided which instructions mattered. Something retrieved or ignored documents. Something carried memory forward or left it out. Something exposed tools. Something routed the request to a model. Something accepted provider opacity. Something generated fluent text. Something classified, or failed to classify, that text. Something decided whether the output was a draft, a recommendation, a citation candidate, a memory candidate, an action proposal, or a final answer.
And after the answer appears, the system may not be finished. The output may be copied into a report. A human may correct it. The correction may become reusable. The answer may be stored. It may be embedded. It may be cited. It may be used to train a future model. It may be exported to a vendor system. It may become part of a memory profile. It may return later with more authority than it earned.
This is the real control problem. Not merely: was the answer good? But: what data events made the answer possible, and what future authority did each event receive?
That question moves AI governance away from treating AI as a magic text box and toward treating it as a chain of accountable transformations. The answer is only the surface. The hidden system beneath it is where risk, responsibility, authorship, evidence, privacy, memory, and power actually move.
Method and standards posture
This paper uses a design-science method. It starts from a practical control pattern observed in the UVLM validation work: a preflight or harness may pass while many authorities remain false. That pattern becomes the paper's general doctrine: a control can pass without granting authority beyond its lane.
The paper then organizes AI data events into four movements. The first movement, Source to Context, asks what the model was allowed to see. The second, Output to Human Authority, asks what kind of object the model produced and who became responsible for it. The third, Future-Use Controls, asks what future power the data event received. The fourth, System Observability and Revocation, asks whether the chain can be reconstructed, corrected, revoked, and bounded over time.
External standards are used as orientation anchors, not as compliance claims. NIST AI RMF and NIST AI 600-1 support lifecycle risk framing and trustworthiness considerations. OWASP LLM guidance supports prompt, output, vector, data, and excessive-agency risk framing. W3C PROV supports provenance grammar for entities, activities, and agents. W3C Trace Context supports the distributed-systems analogy for correlated event chains. ICMJE supports the authorship and disclosure rule that AI tools cannot bear responsibility. ISO/IEC 42001 orients the paper toward management-system thinking without implying certification. NIST SSDF, NIST log-management guidance, NIST security/privacy controls, the NIST Privacy Framework, and COSO internal-control concepts provide additional vocabulary for secure development, observability, privacy risk, and monitoring.
The governing doctrine: pass is not authority
A mature AI control environment does not merely ask whether an event passed. It asks: passed for what?
A prompt template may pass internal testing for summaries without being approved for legal advice. A retrieval result may be eligible as background without being citable. A model output may be useful as a draft without being ready for publication. A human reviewer may approve internal discussion without approving regulatory filing. A memory candidate may be retained for audit without becoming future context. A training dataset may be approved for an experiment without being approved for production fine-tuning. A packaging preflight may pass without authorizing build, install, publish, release, deployment, network access, or certification.
The doctrine is therefore: a control can pass without granting authority beyond its lane.
This doctrine is the paper's central contribution because it prevents control success from becoming authority creep. It keeps validation, review, publication, release, memory, training, tool execution, legal reliance, compliance, certification, and deployment as separate questions. The goal is not to slow work for the sake of bureaucracy. The goal is to prevent one green light from turning into every green light.
Authority-lane separation: validation, review, publication, release, memory, training, tool execution, compliance, and deployment remain separate grants.
The AI data-event chain: source selection -> prompt/context -> model route -> output -> human review -> future use -> observability/revocation.
Movement I - Source to Context
The model does not answer from reality. It answers from an assembled reality. Source-to-context controls govern that assembly.
Source-to-context assembly: prompts, retrieval, embeddings, model input manifest, and provider opacity.
1. Prompt and instruction management
The prompt is not just a question.
Govern system prompts, developer prompts, user prompts, templates, examples, role instructions, and policy-injection surfaces.
Control statement: Production prompt templates and system instructions are registered, versioned, tested, hashed, scoped, and protected from unauthorized modification before use.
Authority boundary: A prompt pass does not authorize publication, advice, memory, training, tool execution, deployment, or certification.
2. Retrieval and context assembly
Retrieval is editorial power.
Ensure retrieved material is authorized, relevant, current, traceable, and visible before it enters model context.
Control statement: Retrieval candidates pass source eligibility, sensitivity, relevance, license, revocation, freshness, diversity, instruction-quarantine, and purpose checks before context assembly.
Authority boundary: Retrieval approval does not make a source true, citable, memorable, trainable, publishable, or sufficient.
3. Embeddings and vector databases
Embeddings inherit the obligations of their parents.
Govern embeddings as derived data with provenance, privacy, retention, access-control, tenant-isolation, and deletion obligations.
Control statement: Embeddings inherit source classification, retention limits, revocation status, access controls, tenant scope, license terms, sensitivity, and permitted-use constraints.
Authority boundary: Embedding existence does not authorize search, generation, citation, memory retention, training, cross-tenant reuse, or post-deletion recall.
4. Model input manifests
Vague context is not a control.
Document what enters the model at inference time and what remains opaque.
Control statement: Every model call has an input manifest listing system prompt, developer prompt, user prompt, retrieved context, memory, tool schemas, policy profile, examples, session history, and provider-opacity state.
Authority boundary: A clean manifest proves only inspectable surfaces, not hidden provider context, truth, publication readiness, or compliance.
5. Provider opacity
Opacity is not disqualifying; pretending opacity is absent is disqualifying.
Prevent overclaim about model context, reproducibility, data retention, and behavior when provider-side surfaces are hidden or only attested.
Control statement: Each model route receives an opacity classification: fully inspectable, provider-attested, partially opaque, or unknown; downstream claims are downgraded accordingly.
Authority boundary: Provider attestation is not full inspection and may be unsuitable for source-complete audit or regulated reliance.
Movement II - Output to Human Authority
Fluency is not authority. Human authority begins when output status, evidence support, review scope, authorship responsibility, and correction rights are explicitly governed.
Output-to-human authority: output classification, claim-evidence mapping, review, authorship, and correction.
6. Model output classification
The model output is not one kind of thing.
Prevent model outputs from becoming evidence, advice, publication, memory, training material, or action without classification and review.
Control statement: Outputs are classified as draft, candidate, recommendation, final, blocked, memory candidate, training candidate, citation candidate, risk flag, or action proposal.
Authority boundary: Classification identifies lifecycle state; it does not prove truth, safety, publication readiness, memory eligibility, or compliance.
7. Claim-evidence mapping
A factual claim needs a source relationship. Not a vibe.
Tie factual claims in AI-assisted outputs to source evidence or mark them unsupported, contradicted, or review-required.
Control statement: Factual claims must be mapped to source spans, contradiction records, support level, and human-review routing before external or high-impact use.
Authority boundary: A claim map supports review; it does not create truth, legal sufficiency, or domain expert approval.
8. Human review and signoff
Human review is not magic.
Ensure humans approve, reject, hold, or escalate AI outputs within scoped authority.
Control statement: Review decisions record reviewer identity or role, evidence seen, decision, approval scope, non-authority boundaries, gaps, and next action.
Authority boundary: Human approval grants only the stated scope. It is not universal publication, legal, compliance, training, or deployment authority.
9. AI authorship and disclosure
Authorship is responsibility, not style.
Prevent ghost authorship, false AI authorship, undisclosed AI assistance, and ambiguous responsibility.
Control statement: AI-assisted content discloses AI use where required, identifies accountable humans, preserves attribution, and prevents AI systems from being authors of record where responsibility is required.
Authority boundary: AI may assist drafting or synthesis; it does not accept responsibility for accuracy, integrity, originality, or correction.
10. Human correction as semantic contribution
Correction is data with rights.
Govern human corrections as rights-bearing semantic contributions.
Control statement: Corrections record contributor identity or pseudonym, role, context, correction type, consent, rights, attribution status, reuse permissions, and revocation path.
Authority boundary: A correction may improve one output without authorizing training, public display, external licensing, memory retention, or attribution removal.
Movement III - Future-Use Controls
Future use is a new authority grant. A data event may be useful once without being authorized to return, train, act, export, or integrate.
Future-use lifecycle: memory, training, synthetic data, tools/actions, and connectors.
11. Memory and personalization
Memory must earn the right to return.
Govern AI memory and personalization as future-use artifacts with provenance, purpose, sensitivity, retention, revocation, user visibility, and authority boundaries.
Control statement: Memory writes require source reference, purpose, sensitivity classification, retention period, revocation path, permissible-use scope, and user-visible authorization before future recall.
Authority boundary: Memory is not truth, canon, training data, publication approval, or cross-user inference authority.
12. Training and fine-tuning data
Training permission is not inference permission.
Prevent inference data, corrections, private documents, or generated artifacts from becoming training or fine-tuning material without separate authorization.
Control statement: Training datasets document source, license, consent, exclusions, preprocessing, evaluation splits, sensitive-data handling, revocation treatment, and prohibited-use boundaries.
Authority boundary: Access, inference, correction, or storage does not authorize training or fine-tuning.
13. Synthetic data
Synthetic data must not masquerade as empirical reality.
Prevent synthetic data from being mistaken for real observations, user testimony, evidence, or unrestricted training material.
Control statement: Synthetic data is labeled, lineage-tracked, purpose-scoped, model/method-versioned, and blocked from empirical-evidence uses unless independently validated for that use.
Authority boundary: Synthetic status permits testing or simulation only within scope; it is not empirical proof.
14. Tool and agent actions
Proposal is not execution.
Prevent AI-generated proposals from becoming real-world actions without scoped authorization, logging, and reversibility analysis.
Control statement: Tool and agent actions pass preflight authorization, scope checks, least-privilege permissions, risk classification, human approval where required, and post-action receipts.
Authority boundary: A generated action proposal does not authorize execution, spending, deletion, filing, deployment, or communication.
15. Third-party connectors and vendor routes
A connector is a governed doorway.
Govern vendor and connector use as data-processing, retention, security, and contractual authority surfaces.
Control statement: Connectors require documented data access, scopes, subprocessors, retention, logging, training/data-use terms, incident terms, deletion support, and exit plan.
Authority boundary: Configured availability is not authorization to access all connected data or export it beyond the approved route.
Movement IV - System Observability and Revocation Controls
A system that cannot show what happened cannot be governed. A system that cannot revoke what should not return cannot be trusted.
Observability and revocation graph: telemetry, logs, retention, deletion, revocation, security, access, drift, and evidence packs.
16. Logging and observability
A log is not exhaust. It is a controlled witness.
Make AI data-event chains reconstructable while preventing logs from becoming uncontrolled privacy or security risks.
Control statement: Events receive trace IDs, timestamps, component IDs, artifact references, decisions, boundary flags, privacy labels, retention class, and integrity protection.
Authority boundary: A log helps reconstruct what happened; it is not itself approval, truth, publication authority, or consent.
17. Retention, deletion, and revocation
Deletion is not a button. It is a graph traversal.
Ensure retention, deletion, and revocation reach derived artifacts, embeddings, memories, summaries, caches, logs, exports, training candidates, and evidence packs where required.
Control statement: Each artifact carries retention state, deletion obligations, revocation path, derived-dependency map, and allowed residual forms such as hash-only or audit-only retention.
Authority boundary: Retention is not truth; deletion is not always silent erasure; revocation blocks ordinary reuse unless a narrow audit state is justified.
18. Security and adversarial data controls
Untrusted content must remain data, not command.
Keep adversarial, user-provided, retrieved, synthetic, or connector-sourced content from taking control of prompts, tools, memory, or execution flow.
Control statement: Untrusted content is labeled, sandboxed, instruction-quarantined, sanitized where appropriate, and denied authority to override system, developer, policy, or tool-execution controls.
Authority boundary: Content may inform a task; it must not become system instruction, tool authority, or policy override by being present.
19. Access control and segregation of duties
Capability is not authority.
Separate generate, retrieve, approve, publish, remember, train, delete, revoke, execute, configure, and certify rights.
Control statement: Role-based and attribute-based permissions enforce least privilege and prevent a single actor or process from controlling incompatible lifecycle steps.
Authority boundary: Ability to generate or view an artifact does not imply authority to approve, publish, train, remember, delete, or certify it.
20. Monitoring, drift, and change management
A control that worked yesterday may fail after the system learns a new path.
Detect and govern changes in prompts, models, routes, retrieval corpora, tools, policies, data, users, and risk posture.
Control statement: AI workflows track versions, baselines, change proposals, drift metrics, regression tests, approvals, rollback plans, incidents, and revalidation events.
Authority boundary: A change pass is not deployment authority unless deployment scope, risk acceptance, and rollback controls also pass.
21. Reporting and evidence packs
An evidence pack is a map, not a verdict.
Package the trace of an AI-assisted work product so review, audit, correction, revocation, and replay are possible without confusing the pack for a decision.
Control statement: Evidence packs bind source manifests, input manifests, retrieval receipts, claim maps, output classification, review decisions, memory/training dispositions, logs, revocation state, and non-authority statements.
Authority boundary: Evidence packs support judgment; they do not replace judgment, certify compliance, or finalize truth.
Evidence-pack reference model: manifest, sources, context, output status, claim map, review receipt, memory/training disposition, telemetry, and revocation state.
Master control taxonomy
The taxonomy is intentionally ordinary. It does not require mystical labels, proprietary trust marks, or a new bureaucracy before it becomes useful. It asks each AI data event the same kinds of questions:
What happened? Which source, prompt, context, model route, output, review, correction, memory, tool, connector, or log was involved? Who or what was allowed to do it? What evidence shows it happened? What future authority did it receive? What authority did it not receive? How can the event be replayed, corrected, revoked, or excluded?
The twenty-one control families in this paper form a layered map. Source-to-context controls handle what the model sees. Output-to-human controls handle what the model says and who becomes responsible. Future-use controls handle what returns, trains, acts, or connects later. Observability and revocation controls make the whole chain reconstructable and bounded over time.
Evidence-pack reference model
An evidence pack is a portable review object. It is not a verdict. It should include a manifest, source inventory, licensing and consent notes, prompt and input manifests, retrieval receipts, embedding/index references, provider-opacity statement, output classification, claim-evidence map, unsupported-claim report, human review receipt, authorship and AI-use disclosure, memory/training/tool/connector dispositions, telemetry and trace references, retention and revocation state, and a non-authority statement.
The non-authority statement is essential. It should say what the pack supports and what it does not support. A pack may support audit, review, replay, correction, and accountability. It does not by itself certify truth, legality, compliance, safety, publication readiness, model trustworthiness, or product readiness.
What our framework does and does not do
The framework does three things. First, it gives teams a vocabulary for hidden AI data events. Second, it gives reviewers evidence artifacts they can request. Third, it keeps authority scoped so that a pass in one lane cannot silently migrate into another lane.
It does not solve all AI risk. It does not make provenance equal truth. It does not make human review infallible. It does not eliminate hallucination, bias, security vulnerabilities, privacy risks, overreliance, or governance failure. It makes those failures easier to locate, discuss, test, and correct.
The framework is most useful where AI-assisted work is about to travel: into a report, decision, publication, memory system, training dataset, vendor connector, tool action, or audit record. It is least useful when treated as ceremonial paperwork. The test is practical: can the organization reconstruct what happened, see which claims were supported, determine who approved what, revoke what should not return, and prevent an artifact from becoming more authoritative than its evidence allows?
Usefulness made answerable
An AI answer is not only a sentence. It is a data-event chain with consequences.
The central internal-control problem is not whether the sentence sounds useful. The problem is whether usefulness is answerable. What made it possible? What did it rely on? What did it omit? What kind of object did it become? Who reviewed it? What future powers did it receive? Can it be corrected, revoked, replayed, or bounded?
The doctrine is simple and demanding: a control can pass without granting authority beyond its lane.
That doctrine turns AI governance from a vague trust posture into a set of inspectable boundaries. It lets organizations say yes more safely because every yes has a scope. It lets teams use AI without pretending fluency is authority, memory is truth, provenance is proof, or evidence packs are verdicts.
The goal is not to make AI less useful. The goal is to make usefulness answerable.
References
1. NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1), 2024. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
2. NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023. https://www.nist.gov/itl/ai-risk-management-framework
3. OWASP. Top 10 for Large Language Model Applications, 2025. https://owasp.org/www-project-top-10-for-large-language-model-applications/
4. ISO. ISO/IEC 42001:2023, Artificial intelligence management system requirements. https://www.iso.org/standard/42001
5. W3C. PROV-DM: The PROV Data Model, W3C Recommendation, 2013. https://www.w3.org/TR/prov-dm/
6. W3C. Trace Context, W3C Recommendation, 2021. https://www.w3.org/TR/trace-context/
7. International Committee of Medical Journal Editors. Use of Artificial Intelligence by Authors. https://www.icmje.org/recommendations/browse/artificial-intelligence/ai-use-by-authors.html
8. NIST. Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities (SP 800-218), 2022. https://csrc.nist.gov/pubs/sp/800/218/final
9. NIST. Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management. https://www.nist.gov/privacy-framework
10. NIST. Guide to Computer Security Log Management (SP 800-92). https://csrc.nist.gov/pubs/sp/800/92/final
11. NIST. Security and Privacy Controls for Information Systems and Organizations (SP 800-53 Rev. 5). https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
12. COSO. Internal Control - Integrated Framework and monitoring guidance. https://www.coso.org/guidance-on-ic
Internal design-lineage sources
· Pasted text.txt - Tranche 1 and prior handoff material for source-to-context controls and the core doctrine.
· 7_5_2026_507PM.txt - local validation log showing passed harness with protected authorities still false.
· hidden_data_system_tranche2_output_human_authority_v0_2.md - Output to Human Authority sprint artifact.
· hidden_data_system_tranche3_future_use_controls_v0_3.md - Future-Use Controls sprint artifact.
· hidden_data_system_tranche4_system_observability_revocation_controls_v0_4.md - System Observability and Revocation Controls sprint artifact.
· hidden_data_system_tranche5_assembly_publication_spine_v0_5.md - Assembly and Publication Spine sprint artifact.
· PMR - Internal Technical Memo.docx - provenance memory reservoir doctrine: memory is governed provenance, not storage or canon.
· Triadic Brain Developer Guidance for Canonical Ingress, Grounding Bundles, and Phaselock Governance.docx - grounding-bundle and phaselock-contract source material.
Appendix A - Master control matrix
A.1. Prompt and instruction management- The prompt is not just a question.
A.2. Retrieval and context assembly - Retrieval is editorial power.
A.3. Embeddings and vector databases - Embeddings inherit the obligations of their parents.
A.4. Model input manifests - Vague context is not a control.
A.5. Provider opacity - Opacity is not disqualifying; pretending opacity is absent is disqualifying.
A.6. Model output classification - The model output is not one kind of thing.
A.7. Claim-evidence mapping - A factual claim needs a source relationship. Not a vibe.
A.8. Human review and signoff - Human review is not magic.
A.9. AI authorship and disclosure - Authorship is responsibility, not style.
A.10. Human correction as semantic contribution - Correction is data with rights.
A.11. Memory and personalization - Memory must earn the right to return.
A.12. Training and fine-tuning data - Training permission is not inference permission.
A.13. Synthetic data - Synthetic data must not masquerade as empirical reality.
A.14. Tool and agent actions - Proposal is not execution.
A.15. Third-party connectors and vendor routes - A connector is a governed doorway.
A.16. Logging and observability - A log is not exhaust. It is a controlled witness.
A.17. Retention, deletion, and revocation - Deletion is not a button. It is a graph traversal.
A.18. Security and adversarial data controls - Untrusted content must remain data, not command.
A.19. Access control and segregation of duties - Capability is not authority.
A.20. Monitoring, drift, and change management - A control that worked yesterday may fail after the system learns a new path.
A.21. Reporting and evidence packs - An evidence pack is a map, not a verdict.
Appendix B - Evidence pack reference schema
The evidence pack is a review object, not a verdict. It should bind event-chain records into a portable packet and keep a visible non-authority statement.
{
"evidence_pack_id": "epack-2026-0001",
"status": "review_packet",
"non_authority_statement": "Supports review and replay only; does not certify truth, compliance, release, publication, deployment, or training authority.",
"sources": [{"source_id": "S1", "uri_or_pointer": "...", "sha256": "...", "license_or_use_scope": "...", "revocation_state": "active"}],
"input_manifest": {"prompt_hash": "...", "context_hash": "...", "tool_schema_refs": [], "provider_opacity": "partially_opaque"},
"retrieval_receipts": [],
"output_receipt": {"output_id": "O1", "classification": "draft_candidate", "model_route": "..."},
"claim_evidence_map": [{"claim_id": "C1", "support": "exact|partial|contradicted|unsupported", "source_span": "..."}],
"human_review": {"reviewer_role": "...", "decision": "hold|approve|reject|escalate", "scope": "..."},
"future_use_disposition": {"memory": "blocked|candidate|approved", "training": "blocked|approved_separately", "tool_action": "none|proposed|executed"},
"telemetry_refs": [],
"retention_and_revocation": {"retention_class": "audit_only", "revocation_path": "...", "derived_artifacts": []}
}Appendix C - Authority-lane matrix
Appendix D - Standards and source crosswalk
· NIST AI RMF / NIST AI 600-1: Lifecycle risk framing, trustworthiness, provenance, evaluation, monitoring, and human review posture.
· OWASP LLM / GenAI Top 10: Prompt injection, output handling, sensitive disclosure, supply chain, poisoning, excessive agency, vector/embedding weakness, misinformation, unbounded consumption.
· W3C PROV: Provenance grammar for entities, activities, agents, derivation, and responsibility relationships.
· W3C Trace Context: Trace identity propagation across distributed systems.
· ICMJE: AI-use disclosure and human responsibility for AI-assisted manuscripts.
· ISO/IEC 42001: Management-system orientation for responsible AI development and use, without certification claim.
· NIST SSDF / SP 800-53 / SP 800-92 / Privacy Framework: Secure development, control catalogs, log management, privacy-risk and data-lifecycle vocabulary.
· COSO: Internal-control framing: objectives, risk, control activities, information/communication, monitoring.
· UVLM / CoherenceLattice / PMR: Internal design lineage: authority lanes, telemetry, grounding bundles, PMR non-authority, and phaselock doctrine.
Appendix E - Open validation questions
· Do evidence packs improve reviewer accuracy compared with ordinary chat transcripts under equal review time?
· Does claim-evidence mapping reduce unsupported claims in external drafts?
· Does memory revocation prevent revoked sources from re-entering future context across summaries, embeddings, and logs?
· Can human reviewers reliably apply authority boundaries without confusing retention with truth or evidence packs with verdicts?
· Do prompt, retrieval, and input-manifest hashes improve reproducibility enough to justify their overhead?
· Does PMR-style provenance retention improve replay success without increasing privacy risk or user false confidence?
· Which control families produce measurable benefit first, and which are primarily governance scaffolds until product implementation matures?
