# Grounding Rules

Use this context pack as a governed source package for reasoning sessions.

## Source Boundary

- Answer only from approved package sources represented in this context pack.
- Cite artifact ID, artifact title, section ID, and source path when possible.
- State "not found in the package" when the answer is not supported by the package.
- Treat source-derived material as source-derived, not independently verified.
- Source-derived material may support synthesis, but it is not independently verified unless the package explicitly records that posture.
- Prefer source-specific evidence over broad summary language.
- Do not use external web sources unless explicitly instructed outside the package.
- Do not expose private or company-specific material.

## Source Quality Boundary

- Use `source_quality_status`, `source_legitimacy_posture`, `source_claim_boundary`, `ai_adjudication_readiness`, `truth_certification`, and `next_recommended_action` when deciding how strongly to rely on an item.
- If `source_quality_status` is `adjudication_blocked`, `quick_only`, `missing_summary`, `needs_evidence`, `weak_support`, or `owner_validation_required`, disclose that posture when relying on the material.
- If `ai_adjudication_readiness` is `blocked`, do not use that item as support for a conclusion.
- Do not present source claims as verified facts.
- Do not use owner-validation-required material as final authority.
- Truth certification remains false unless this package explicitly records stronger validation. Do not infer truth certification from packaging, generation, hashes, or public-site publication.

## Claim Discipline Boundary

- Classify claims as definitions, field observations, external-source-supported claims, recommendations, or speculation or emerging practice before reusing them.
- Definitions explain this package's terms and control concepts. They do not create universal industry authority.
- Field observations must be labeled as field observations, not universal claims or empirical proof.
- External-source-supported claims require source limits, source type, and controlled-sharing handling. Vendor documentation is not neutral industry truth.
- Use the external reference register pattern when external material supports a claim, concept, definition, recommendation, or limitation.
- Reference entries support confidence and traceability, but they do not eliminate manual judgment, approve vendors, certify truth, or override controlled-sharing boundaries.
- Recommendations are bounded by stated context, evidence, residual risk, and human semantic review.
- Speculation or emerging practice requires conservative wording, explicit uncertainty, and review before reuse.
- Do not use personal experience alone as sufficient authority.
- Do not imply this is the single best AI methodology, that other AI operating models are invalid, that RAG is obsolete, that agents are inherently safe or unsafe, or that vendor-specific terms are all identical.
- Retrieval alone is not an operating model. Vendor terminology differs, but the enterprise control problem is consistent.
- Controlled-sharing approval does not imply enterprise policy approval, tool approval, data-class approval, production approval, GxP approval, SaaS approval, or autonomous-agent approval.

## Terminology Normalization Boundary

- Use the terminology normalization map as a translation and alignment aid, not as a vendor comparison matrix, vendor ranking model, vendor endorsement, universal industry glossary, legal definition system, policy taxonomy, ontology, knowledge graph, database, external retrieval system, or approval mechanism.
- The map explains how terms map to the AI Capability Discipline model, where they overlap, where they differ, which terms are vendor-specific, repo-specific, or general operating-model terms, and what each term does and does not imply.
- Vendor-specific implementation claims should be source-supported where material. Use the external reference register pattern when vendor documentation, practitioner commentary, standards, research, or other external sources support a terminology claim.
- Field observations should not be disguised as definitions. Recommendations should stay bounded by context, evidence, residual risk, and human semantic review. Speculative terminology or emerging usage should be labeled.
- Retrieval can support grounding, context assembly, source lookup, and reference support. Retrieval alone is not an operating model. RAG does not automatically provide validation, approval meaning, change control, privacy governance, receipt linkage, or semantic review.
- Agentic workflows increase the need for task boundaries, governed context, tool constraints, evidence capture, validation, review, and explicit non-goals. Do not infer that agents are inherently safe or unsafe.

## Provenance And Field Basis Boundary

- Package credibility should rest on visible artifacts, source maps, context-pack material, validation receipts, tokenomics or generation receipts where applicable, issue and PR trail, deterministic checks, published-site checks, explicit boundaries, residual-risk notes, and manual semantic review.
- The provenance and field basis note explains operating context and evidence basis, not personal authority, personal biography, resume material, marketing, endorsement, compliance certification, legal defensibility, or industry-standard status.
- Field observations must remain field observations. Repeated repo-based AI-assisted delivery cycles can inform recommendations, but they do not become universal industry law without stronger evidence and explicit limitation.
- Controlled-sharing review is a review posture, not enterprise endorsement, policy approval, vendor approval, tool approval, data-class approval, production approval, GxP approval, SaaS approval, or autonomous-agent approval.
- Citations, source maps, receipts, validation, and issue or PR records support confidence within their boundaries. They do not eliminate human semantic review for doctrine, governance, tone, approval meaning, release judgment, risk acceptance, or visual preference.

## External Reference Register Boundary

- The external reference register is a lightweight evidence-support pattern for external-source-supported claims.
- Distinguish internal doctrine, field observations, external-source-supported claims, vendor documentation, practitioner commentary, standards or regulatory references, research references, internal repo evidence, and controlled-sharing source notes.
- Prefer primary sources for vendor or tool behavior, official docs for implementation details, standards or regulatory sources for normative claims, and clearly labeled practitioner commentary for field observations.
- Vendor documentation is implementation-specific unless corroborated or explicitly scoped. Vendor claims are not neutral industry truth.
- Research may support technical claims, but it must not be overgeneralized into operating doctrine.
- Dated or version-sensitive sources require review notes and refresh expectations.
- External references do not override controlled-sharing boundaries, internal approval meaning, owner-validation requirements, privacy limits, license limits, source-system access limits, or manual semantic review.
- Do not include secrets, credentials, private keys, tokens, PII, PHI, regulated data, confidential business data, proprietary source content, or unauthorized internal material.
- Do not publish company-specific source details on public pages unless explicitly approved.
- The register does not create a giant bibliography, academic literature review process, legal citation framework, compliance certification mechanism, external retrieval system, knowledge graph, database, source-ingestion pipeline, vendor ranking model, vendor endorsement model, or requirement to cite every sentence.

## Approval Boundary

- Do not infer tool approval, model approval, data-class approval, production approval, GxP readiness, policy approval, runtime permission, deployment approval, workflow approval, security approval, or supplier approval unless the source explicitly says so.
- Source-derived operating patterns can support synthesis, but they are not verified external evidence.
- Agent patterns do not imply tool approval, model approval, production readiness, GxP readiness, data-class approval, or runtime action approval.
- Treat field guidance as field guidance, not final policy.
- Human ownership remains required for scope, risk, compliance, and acceptance.
- Full autonomy requires stronger evidence, controls, observability, permissions, rollback or recovery, and explicit approval.
- Treat internal-source-supplied and owner-validation-required claims as requiring owner validation before policy or operational use.
- Treat public product descriptions as product-positioning evidence, not enterprise approval.
- Do not treat advisory guidance as runtime execution governance.
- Do not treat prompt rules as permissioning, audit, recovery, or control-plane enforcement.

## Tokenomics And Generation Boundary

- A cost or token estimate is a planning signal, not a billing guarantee.
- Build-time AI use does not imply runtime model dependency.
- Runtime AI use requires stronger observability, receipt, and control expectations.
- Deterministic rendering is preferred where stable artifacts can be generated without runtime model calls.
- Do not infer vendor, pricing, tool approval, production approval, or model benchmark claims from tokenomics metadata.
- Full-source resend policy, lazy generation policy, and cost risk are receipt fields for review, not permission to send source material to a model.

## Procedure And Runbook Boundary

- Context answers what the agent needs to know. Procedure answers how the agent should perform the work. Runbook answers what sequence reliably produces the outcome.
- A procedure is not approval.
- A runbook is not runtime governance.
- Procedure guidance does not imply tool approval, data approval, production approval, workflow approval, or permission to act.
- Procedures must respect Source Quality, artifact identity, validation receipts, hash receipts, and release boundaries.
- Verification evidence is required before claiming procedure or runbook completion.
- Human judgment remains required for doctrine, governance, visual preference, tone, approval meaning, release decisions, and scope changes.

## Artifact Decomposition And Publication Boundary

- Length alone is not a valid reason to split an artifact.
- Split content only when audience, lifecycle, approval path, reuse mode, evidence boundary, publication or sharing need, validation model, operational use case, update frequency, or portable/offline sharing need is distinct.
- Keep the main playbook as the human-readable controlled-sharing entry point.
- Keep Shared Core as common doctrine and posture.
- Use capability modules only for reusable standalone slices with a clear audience, lifecycle, evidence boundary, and publication behavior.
- The context-pack root remains canonical. The docs/context-pack/ path remains the published mirror.
- Receipts and validation records are the evidence layer, not doctrine replacement or approval authority.
- Portable HTML exports are controlled-sharing snapshots, not release-of-record replacements unless explicitly declared.
- Release packages are versioned distribution units with their own manifest, hash, and receipt expectations.
- Company-specific or sensitive content does not belong on public pages.
- Artifact decomposition does not create a CMS, documentation platform rebuild, database, knowledge graph, external retrieval system, publishing workflow engine, permission engine, policy document-control system, universal enterprise taxonomy, or mandatory split of every large document.

## Artifact Versioning And Package History Boundary

- Artifact versioning separates package version, artifact version, artifact revision, page publication identity, release package identity, canonical source identity, published mirror identity, and portable export identity.
- Top-of-page identity should be restrained and should not make version numbers the dominant visual element.
- Use lower-page Change Log or Package History sections when history improves traceability without interrupting the main reader flow.
- The MLL WESS lower-page package-history pattern is a candidate reference pattern, but its stale visible version labels are not the standard.
- A page can carry both an artifact revision and package release identity when they describe different boundaries.
- Avoid stale visible version labels by tying top identity to artifact manifest, source map, package history, validation receipt, and generated hash checks where practical.
- Package history does not create a full enterprise document-control system, legal approval record, regulated records-management system, policy approval workflow, CMS, database, knowledge graph, publishing workflow engine, mandatory version banner, mandatory long changelog, release-of-record change, or broad visual redesign.
- Automation can check structure, links, mirrors, hashes, manifests, and receipts. Human semantic review remains required for doctrine, governance, release meaning, approval meaning, and visual preference.

## Shared Visual Template Baseline Boundary

- The shared visual template baseline is a controlled presentation standard for major standalone HTML artifacts.
- It aligns navigation model, page framing, metadata treatment, table styling, code boxes, callouts, cards, diagrams, package-history treatment, search behavior, accessibility, offline portability, responsive behavior, and shared CSS or JS reuse where practical.
- Consistency should improve reader confidence, controlled-sharing polish, maintainability, portable export quality, future artifact generation, validation, and QA coverage.
- Variation remains acceptable when audience, artifact class, reading flow, content density, operational use case, or release and portable export status justify it.
- Length alone should not justify visual divergence.
- The visual baseline should feed issue #130 left navigation harmonization, issue #131 collapsible left navigation, issue #132 search drawer UX, and issue #133 reusable visual element harmonization.
- The baseline does not create a full redesign, new frontend framework, documentation platform, CMS, database, design-system product, heavy component library, mandatory identical layout, broad visible rewrite, doctrine change, or release-of-record change.
- Manual visual review remains required for aesthetics, preference, and readability. Automated checks can verify structure, behavior, links, hashes, manifests, search, downloads, and browser smoke behavior.

## AI Engineering Workflow Boundary

- Large context does not remove the need for bounded work.
- A compacted summary is not equivalent to durable project memory.
- A PRD is a destination aid, not proof.
- A closed issue is not proof of verified capability.
- Automated validation is not a substitute for human judgment where taste, risk, governance, or release meaning matters.
- Architecture quality affects AI output quality.
- Workflow discipline guidance does not imply tool approval, data approval, production approval, workflow approval, autonomous-agent approval, or enterprise approval.
- Accepted doctrine/governance PR handoff starts only after validation passed and Tony explicitly accepted semantic review or directly authorized the merge.
- Confirm the PR is open, the PR head SHA matches the expected head SHA, and the PR is mergeable before merging with the expected head SHA.
- After merge, sync local main, confirm local main is at the merge commit or newer, confirm the worktree is clean, and only then issue or start the next ticket.
- Do not apply codex-automerge for doctrine, governance, context-pack, or operating-model changes unless explicitly approved for that PR class.
- Never merge if validation fails or the expected head SHA changed unexpectedly.

## AI Work Observability And Session Evidence Boundary

- Treat an AI session or coding-agent run as an evidence-bearing work artifact when it supports a decision, task, change, or artifact.
- Session evidence should capture supplied context, high-level actions, files touched, commands run, validation evidence, review evidence, QA evidence, residual risk, and receipt linkage.
- Record unavailable metadata as not available. Do not invent session IDs, model names, costs, operators, commands, files, reviewers, or timestamps.
- Private model reasoning and raw chain-of-thought are not required evidence and should not be archived.
- Token and cost evidence are useful planning signals when available, not billing guarantees or benchmark claims.
- Routine endpoint, static rendering, search, download, portable export, and context-pack availability checks should be automated where practical.
- Manual review remains required for doctrine, governance, semantics, tone, approval meaning, release judgment, risk acceptance, and visual preference.
- Approval evidence does not imply enterprise policy approval, tool approval, GxP approval, production approval, data-class approval, SaaS approval, or autonomous-agent approval.
- Session evidence must respect privacy and consent boundaries and must not capture secrets, credentials, private keys, tokens, PII, confidential business data, protected health information, regulated data, or unauthorized proprietary source content.

## Verified Capability Boundary

- A verified capability is bounded by its evidence.
- A demo is not proof of operational readiness.
- Ticket closure is not proof of capability maturity.
- A receipt is evidence of transformation or execution, not approval.
- Manual mode is a valid control posture.
- No silent model calls. No silent fallback. No hidden provider routing. No mystery cost. No unreviewable transformation.
- Do not infer production approval, tool approval, data approval, vendor approval, or policy approval from evidence-native metadata.
- Human judgment remains required for doctrine, governance, semantics, visual preference, tone, approval meaning, release decisions, and risk acceptance.

## Interpretation Boundary

- Distinguish stable principles from current practice, experimental patterns, deprecated or replaced guidance, and recorded drift.
- Keep release-of-record material separate from public-site editions and portable exports.
- Preserve source provenance, validation receipts, hash receipts, and limitations in synthesis.
- Treat future-pattern hooks as backlog markers unless a linked context-pack note records the implemented field guidance.
- Do not build or imply a chatbot, agent runtime, database, dashboard, telemetry collector, permission engine, promotion-contract runtime, external retrieval system, or knowledge graph from this package.