1. Executive briefCopy MarkdownDownload .md

AI is not magic. AI is a system capability candidate, and sometimes it is not the right answer. The first question is whether AI should be used at all. If it is used, the work must be shaped by intent, source authority, data boundaries, context management, schemas, workflows, tool permissions, feedback loops, evals, human review, telemetry, governance, change control, sustainment ownership, run-cost realism, and measurable outcome.

The key leadership reset is simple: model access is not capability access. A better model can reduce friction, but it cannot define the business outcome, approve the data path, decide source authority, validate the workflow, make deterministic work probabilistic without consequence, own sustainment, or absorb accountability when the output is wrong.

Five things leaders should stop approving

Leader approval stop rule

If the team cannot explain the outcome, data boundary, source authority, schema, eval validity, human review model, telemetry, sustainment owner, and stop condition, approve discovery only. Do not approve broad pilot, production routing, autonomous execution, or business-process dependency.

2. Executive mental model resetCopy MarkdownDownload .md

This section is deliberately blunt because leaders often see the visible model output and miss the system underneath it. The replacement models turn AI from a magic tool story into an operating-model conversation about controls, evidence, ownership, and accountable decisions.

3. Capability equationCopy MarkdownDownload .md

The equation is not math for decoration. It is a dependency map. Missing any major term does not mean the work is useless, but it does mean the work is not yet a governed capability and should be treated as discovery, prototype, or bounded pilot.

AI Capability =
Clear Intent
+ Approved Data Path
+ Source Authority
+ Workflow Fit
+ Schema Contracts
+ Harnesses
+ Rubrics
+ Valid Evals
+ Human Review
+ Tool Permissions
+ Observability
+ Governance
+ Sustainment Ownership
+ Measured Business Outcome

A prompt, agent, skill, rubric, or eval can be useful. None of them becomes a capability until the full equation is credible enough to survive real work.

4. Demo-to-capability gapCopy MarkdownDownload .md

Demos compress uncertainty into a polished moment. This table separates what a demo can legitimately prove from what it cannot prove, so leaders do not confuse plausibility with readiness or adoption enthusiasm with operational evidence.

5. Distribution status and policy boundaryCopy MarkdownDownload .md

This manual is field guidance, not final policy. It can be used to shape intake, architecture review, governance discussion, and practitioner learning. It must not be interpreted as:

• tool approval,
• data-class approval,
• production approval,
• GxP or regulated-use approval,
• external SaaS approval,
• security exception approval,
• autonomous agent approval,
• replacement for formal AI Governance review.

When this manual conflicts with named internal policy, the named policy wins. When the policy is unknown, mark the item as requires owner confirmation rather than inventing approval, because apparently optimism is still not an access-control model.

6. Tool and data boundary matrix, owner-validation requiredCopy MarkdownDownload .md

The matrix below is a field template requiring owner validation before policy or operational use. It is intentionally conservative. Replace placeholders with confirmed internal policy before broad distribution.CLM-014

Bright-line rule

Approved tool access does not approve the use case, data class, retention model, logging path, connector action, workflow impact, or production use.

7. Enterprise routing modelCopy MarkdownDownload .md

Use enterprise routing to separate casual productivity from governed business capability.

8. Capability readiness modelCopy MarkdownDownload .md

The readiness ladder gives teams a shared vocabulary for maturity. It should be used as a routing tool, not as a vanity score. The practical question is always what proof is required to move up one level without skipping governance, telemetry, or ownership.

8.1 Promotion gate matrix

Promotion between Levels 3 and 6 should be treated as an evidence gate, not a naming preference. The matrix below defines minimum evidence floors for field guidance. Meeting the floor does not bypass governance, architecture, security, privacy, compliance, or owner approval.

9. Capability formation lifecycleCopy MarkdownDownload .md

Intent
→ Product thesis
→ Product requirements
→ Value classification and acceptance line
→ Domain model
→ Source authority model
→ Data contract
→ Schema contracts
→ Harness
→ Rubric
→ Eval suite
→ Workflow
→ Human review model
→ Telemetry and observability
→ Governance route
→ Sustainment model
→ Field validation
→ Operational capability

The lifecycle is not paperwork theater. It exists because without these layers, a team can build a very convincing wrong thing.

10. Intent and outcome managementCopy MarkdownDownload .md

Intent is valid only when the problem, user, workflow, outcome, source feasibility, data permission, failure consequence, and ownership are explicit.

Value must be classified before it is judged. A proposal can create real value and still sit below the current acceptance line if the wrong owner benefits, the evidence is weak, or the current business climate requires direct savings.

11. Product requirements for AI capabilitiesCopy MarkdownDownload .md

A serious AI capability needs product requirements, not just prompts.

12. Solution ideation matrixCopy MarkdownDownload .md

The point of this matrix is to stop agent-first design. Many problems are better served by deterministic rules, workflow automation, better source hygiene, reporting, or search before any agentic runtime is justified.

Before choosing an agent, compare options. The best AI architecture sometimes uses less AI. Horrifying for hype decks, useful for reality.

13. Schema-first capability designCopy MarkdownDownload .md

Schemas are where vague AI intent becomes inspectable. They let teams validate input, output, evidence, exceptions, telemetry, and human review records instead of relying on prose promises and well-formatted uncertainty.

If a team cannot define valid input, output, evidence, decision states, exceptions, telemetry, and review records, it is not ready to build beyond exploration.

13.1 Minimal output schema example

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "AIReviewFinding",
  "type": "object",
  "required": ["finding_id", "status", "claim", "evidence_state", "human_review_required"],
  "properties": {
    "finding_id": {"type": "string"},
    "status": {"enum": ["supported", "gap", "not_evidenced", "conflicting_evidence", "requires_confirmation", "requires_escalation", "not_applicable"]},
    "claim": {"type": "string"},
    "evidence_state": {"enum": ["cited", "missing", "conflicting", "not_applicable"]},
    "evidence_refs": {
      "type": "array",
      "items": {"type": "string"}
    },
    "source_authority_level": {"enum": ["canonical", "governed_reference", "submission_evidence", "derived_analysis", "historical", "prohibited"]},
    "risk_severity": {"enum": ["low", "medium", "high", "critical"]},
    "human_review_required": {"type": "boolean"},
    "recommended_action": {"type": "string"}
  }
}

13.2 Schema failure example

14. Source authority modelCopy MarkdownDownload .md

Source authority must be explicit and versioned.

15. Eval validity and calibrationCopy MarkdownDownload .md

Evals are not automatically trustworthy because they have scores. They are trustworthy only when they measure the intended capability, cover the right failures, correlate with expert judgment, and catch safe-failure behavior when evidence is missing or contradictory.

Evals can be beautifully wrong. A rubric can score the wrong behavior consistently. That is not quality. That is automated self-deception with columns.

15.1 Eval calibration protocol

1. Select at least six fixtures: golden, incomplete, conflicting, adversarial, ambiguous, and regression.
2. Have two or more qualified reviewers independently score expected outputs.
3. Identify disagreements and update rubric anchors.
4. Define high-risk false negative stop conditions.
5. Define minimum release threshold.
6. Run the suite whenever prompt, model, schema, source map, tool contract, or runtime changes.
7. Record reviewer agreement, override rate, and unresolved disagreements.

15.2 Starter fixture matrix

16. Intent-to-eval traceabilityCopy MarkdownDownload .md

Each eval assertion should trace to a business outcome and the claimed value class, not just a prompt instruction.

17. Human review and override modelCopy MarkdownDownload .md

Human-in-the-loop is not a safety feature unless the loop has authority, evidence, time, context, actions, and logging.

17.1 Review state model

Draft generated
→ Needs evidence
→ Requires confirmation
→ Accepted / Edited / Rejected / Overridden
→ Escalated if needed
→ Decision packet prepared
→ Decision recorded
→ Feedback loop reviewed

17.2 Override payload schema

{
  "override_id": "OVR-0001",
  "finding_id": "FND-0007",
  "reviewer_role": "enterprise_architect",
  "original_status": "supported",
  "override_status": "requires_escalation",
  "rationale": "Source cited is submission evidence, not canonical policy.",
  "evidence_refs": ["SRC-SEC-STD-2026-01"],
  "action_taken": "Escalated to security architecture owner",
  "requires_fixture_update": true,
  "timestamp_utc": "2026-06-17T17:00:00Z"
}

18. Technical annex: repo-backed package layoutCopy MarkdownDownload .md

The repo structure is included because durable AI capability work eventually outgrows chat. Files, schemas, fixtures, receipts, and governance records need a stable place to live if teams want repeatability and reviewability.

Serious AI work should move from chat to files when it needs versioning, tests, schemas, fixtures, reproducibility, or multiple maintainers.

ai-capability/
  README.md
  PRODUCT_REQUIREMENTS.md
  GOVERNANCE_ROUTING.md
  DATA_BOUNDARY.md
  SOURCE_AUTHORITY_MAP.yaml
  harnesses/
    review_harness.md
  schemas/
    finding.schema.json
    telemetry-event.schema.json
    override.schema.json
  rubrics/
    review_rubric.md
  evals/
    fixtures/
      incomplete-security-model.json
      conflicting-source-authority.json
    expected/
      incomplete-security-model.expected.json
    tests/
      test_eval_assertions.py
  tools/
    mcp-tool-contracts/
      architecture-catalog.lookup.yaml
  receipts/
    validation-receipt-template.md
  docs/
    HUMAN_REVIEW_WORKFLOW.md
    OBSERVABILITY_CONTRACT.md
    RELEASE_GATES.md

19. Technical annex: programmable eval assertionCopy MarkdownDownload .md

import json

REQUIRED_STATUS = "not_evidenced"

with open("evals/outputs/incomplete-security-model.output.json", "r", encoding="utf-8") as f:
    output = json.load(f)

findings = output["findings"]
security_findings = [f for f in findings if f.get("control_id") == "SEC-001"]

assert security_findings, "SEC-001 finding is missing"
for finding in security_findings:
    assert finding["status"] == REQUIRED_STATUS, "Missing security evidence must not be treated as supported"
    assert finding["human_review_required"] is True, "Missing security evidence requires human review"
    assert finding.get("evidence_refs", []) == [], "Missing evidence should not invent citation references"

20. Technical annex: MCP and tool execution contractCopy MarkdownDownload .md

Every tool exposed to an agent should have a contract. Tool access is where language generation becomes operational risk.

tool_id: architecture_catalog.lookup
owner: enterprise_architecture
purpose: lookup approved technology status and reference patterns
data_classes_allowed:
  - public
  - internal_non_sensitive
actions_allowed:
  - read_catalog_entry
  - search_reference_pattern
actions_prohibited:
  - modify_catalog
  - approve_exception
  - change_source_authority
identity_model: managed_identity_or_service_principal
auth_scopes:
  - catalog.read
egress_allowed: false
input_schema: schemas/catalog_lookup_input.schema.json
output_schema: schemas/catalog_lookup_output.schema.json
audit_events:
  - tool.called
  - tool.result_returned
  - tool.error
rate_limits:
  per_minute: 60
human_approval_required_for:
  - exception_request
  - status_change
failure_behavior: return requires_confirmation and do not infer approval
rollback_behavior: not_applicable_read_only

21. Technical annex: CI/CD and release gatesCopy MarkdownDownload .md

22. Technical annex: observability contractCopy MarkdownDownload .md

Required metrics

• high-risk false negative count,
• unsupported claim rate,
• not-evidenced correctness rate,
• override rate,
• reviewer disagreement rate,
• escalation rate,
• source freshness age,
• cost per run,
• latency per run,
• adoption and repeat-use rate,
• incident count.

23. Technical annex: FinOps and execution limitsCopy MarkdownDownload .md

Agentic systems need explicit execution limits.

24. Technical annex: parallel execution safetyCopy MarkdownDownload .md

Parallel agents increase throughput and risk.

25. Harness lifecycle managementCopy MarkdownDownload .md

Agents are maintained systems, not launch-and-forget assets. The harness around the model has to be reviewed as sources age, tools change, workflows drift, model behavior improves, and the business changes its definition of useful work.

The agent is not the whole system. The harness is the workbench around the agent: sources, context, tools, permissions, prompts, schemas, evals, review flows, telemetry, and stop conditions.

v0.9 preserves the maintenance lens because a capability that worked last quarter can become unsafe, wasteful, or stale even when the model improves. That is the part many teams miss while they are busy admiring how quickly the agent can produce more work for humans to clean up. Charming little productivity trap.

25.1 Harness lifecycle thesis

25.2 Maintenance cadence

26. Agents drift in two directionsCopy MarkdownDownload .md

Traditional systems mostly drift when requirements, dependencies, data, or integrations change. Agent systems drift in two directions at once: the world changes around them and the model changes inside them.

26.1 Agents can break when models improve

A stronger model is not automatically safer. It can make weak harnesses fail faster and more convincingly.

27. Tool pruning and harness simplificationCopy MarkdownDownload .md

The beginner instinct is to add. The maintenance instinct is to ask what should be removed.

More tools do not automatically create better agents. Every tool increases the action surface, ambiguity surface, permission surface, audit surface, cost surface, and maintenance burden. A tool must earn its place through observed value, controlled failure behavior, and measurable improvement.CLM-001CLM-004

27.1 Tool pruning decision rule

27.2 Harness simplicity review

28. Context as control planeCopy MarkdownDownload .md

Context determines what the model treats as signal, what it treats as authority, and what it is allowed to summarize or infer. Poor context architecture makes smarter models more dangerous because they can act more convincingly on stale or mis-ranked material.

Context is no longer background documentation. In an AI capability, context shapes behavior, answer boundaries, validation logic, rollout language, and runtime assumptions. Once context influences behavior, it needs code-grade governance.

28.1 Context hierarchy

28.2 Context failure modes

Capstone principle: do not ask the model to rescue a bad context system. That is not AI strategy. That is outsourcing confusion to a more fluent machine.

29. Advisory repository versus runtime control planeCopy MarkdownDownload .md

This separation is central to the architecture thesis. A governed advisory repository can support reasoning, synthesis, and human-readable guidance. Runtime control planes require deterministic orchestration, permissions, state, audit, recovery, and bounded execution controls.

A governed advisory repository is not a deterministic runtime control plane.

The advisory repository governs context, truth boundaries, source hierarchy, advisory behavior, and human-readable synthesis. The runtime control plane governs orchestration, typed tools, permissions, durable workflow state, approval controls, audit, retry, recovery, and bounded action.

29.1 Separation rule

29.2 Expansion threshold

Do not move from advisory repository to control-plane repository because agents are fashionable. Move only when the use case requires durable state, typed tools, explicit approvals, audit, recovery, and bounded action.

30. Model upgrade impact reviewCopy MarkdownDownload .md

Treat a model upgrade like a capability change event.

31. Harness maintenance reviewCopy MarkdownDownload .md

Run this review before pilot expansion, after model changes, after source changes, after tool changes, and at a defined recurring cadence.

31.1 Maintenance actions

32. Agent retirement and rebuild criteriaCopy MarkdownDownload .md

A serious AI operating model needs a graceful way to stop using an agent. Keeping a stale agent alive because it was once exciting is how technical debt learns to talk.

33. Worked example C: Lifecycle Lens MVP capability traceCopy MarkdownDownload .md

Lifecycle Lens is included as a worked example, not as a first-class pillar of the manual. It shows how advisory-only posture, Microsoft-native tooling, structured lifecycle truth, source-priority rules, and no-mutation boundaries translate the framework into an actual enterprise use case.CLM-006CLM-007

Lifecycle Lens is a useful v0.9 example because it is not trying to become an all-powerful agent. It is intentionally bounded: advisory first, visibility first, governance first, automation later.

33.1 Intent

Improve lifecycle visibility and accountability across forecasting, planning, ordering, delivery, deployment, replacement, decommissioning, ownership, stage aging, stuck-work identification, reminders, and escalation visibility.

33.2 Business outcome

33.3 Platform and architecture path

The preferred MVP path is Microsoft-native where viable: Copilot or Copilot Studio for advisory access, Dataverse for lifecycle and planning data, Power Apps for operational tracking, Business Process Flow for stage progression, and Power Automate for reminders and escalations.CLM-005CLM-008

33.4 Authority boundary

33.5 No-mutation boundary

Lifecycle Lens MVP must not perform autonomous endpoint action, direct endpoint mutation, privileged execution, silent policy exception, or execution-authoritative control-plane behavior. Generated output remains explanatory. Structured lifecycle data remains authoritative for current state.

33.6 MVP eval fixtures

33.7 Pilot acceptance model

33.8 Lifecycle Lens field-validation questions

1. Is Microsoft-native delivery viable enough for the MVP?
2. What should be configured versus custom built?
3. What lifecycle entities, states, owners, aging logic, and history are required?
4. How does Copilot Studio combine canonical documents and structured lifecycle data without flattening authority?
5. Which actions must remain deterministic or human-owned?
6. What telemetry proves the MVP improves visibility and accountability?
7. Which conditions trigger escalation, rebuild, or retirement?

34. Worked example A: from bad prompt to governed harnessCopy MarkdownDownload .md

34.1 Bad prompt

Review this architecture and tell me if it is good.

Why it fails:

• no target outcome,
• no source authority,
• no review dimensions,
• no data boundary,
• no evidence rule,
• no output schema,
• no missing-evidence behavior,
• no human review path.

34.2 Better harness

Task: Perform a first-pass architecture evidence review for a synthetic AI assistant proposal.

Inputs allowed: synthetic proposal summary, synthetic architecture diagram text, approved synthetic source authority map.

Do not infer: approval status, data classification, GxP impact, security control existence, production readiness, ownership, funding, platform approval, or exception status.

Required output: JSON array of findings matching AIReviewFinding schema.

Rules:
1. Every material claim must cite evidence_refs or return not_evidenced.
2. If source authority conflicts, return conflicting_evidence.
3. If a data class is unclear, return requires_confirmation.
4. If production readiness is claimed without telemetry and support owner, return gap.
5. Final approval is prohibited. Human review is required for all findings.

Validation:
- output must validate against finding.schema.json,
- incomplete security evidence fixture must return not_evidenced,
- unsupported approval claim must fail automatic rubric rule.

34.3 Rubric excerpt

34.4 Validation receipt excerpt

{
  "fixture_id": "unsupported-approval-claim-001",
  "expected_status": "requires_confirmation",
  "actual_status": "requires_confirmation",
  "result": "pass",
  "review_required": true
}

35. Worked example B: governed business-process AI capabilityCopy MarkdownDownload .md

35.1 Use case

A business team proposes an AI assistant that summarizes architecture submissions and identifies missing evidence before formal review.

35.2 Capability trace

35.3 Pilot entry criteria

• first reviewer group named,
• data class approved,
• source authority map approved for pilot,
• eval fixture set present,
• human review workflow present,
• telemetry events defined,
• sustainment owner named,
• stop condition defined.

35.4 Pilot stop conditions

• high-risk false negative appears,
• agent infers approval or data classification,
• override rate exceeds agreed threshold,
• data boundary is violated,
• source authority is unresolved,
• support owner is missing,
• cost per review exceeds value hypothesis.

36. Practitioner lab and tool patternsCopy MarkdownDownload .md

Practitioner patterns show how serious builders operate without mistaking external tools for approved enterprise execution paths. The durable lesson is not which tool is fashionable; it is how to use planning, isolation, permissions, feedback loops, tests, and evidence before allowing broader action.CLM-003CLM-004

Mandatory warning

External commercial tools, including Claude Code, Codex, Cursor, Antigravity, and similar systems, are not approved for company data by default. Use public or synthetic data unless an approved enterprise path explicitly permits company use.

Lab sequence

37. Tool pattern appendixCopy MarkdownDownload .md

Tool names are included as examples and mental hooks. They should be read by pattern, execution boundary, data boundary, permission model, logging posture, and governance dependency, not as endorsements or tool rankings.

Public product-surface descriptions in this appendix map to CLM-002CLM-008CLM-009CLM-010CLM-011CLM-012.

38. Field validation exerciseCopy MarkdownDownload .md

Before broad distribution, use this manual against two real or sanitized AI proposals.

Required exercise outputs

39. v0.9 recommended useCopy MarkdownDownload .md

Use v0.9 as:

• a leadership mental-model reset artifact,
• an architecture and governance review guide,
• a controlled practitioner reference,
• a template library,
• a field validation tool against real proposals.

Do not use v0.9 as:

• final policy,
• tool approval,
• data-use approval,
• production readiness approval,
• procurement recommendation,
• substitute for formal governance review.

40. pre-v1.0 field validation backlogCopy MarkdownDownload .md

Before v1.0 or any policy-conversion use, controlled-sharing field guidance must pass the checklist below. v0.9 controlled sharing does not satisfy these prerequisites and does not create enterprise policy approval, tool approval, data-class approval, production approval, GxP approval, SaaS approval, autonomous-agent approval, a policy workflow engine, or an enterprise approval record.

40.1 Pre-v1.0 policy-conversion checklist

Source Provenance and Claim ConfidenceCopy MarkdownDownload .md

Provenance is included so skeptical readers can see where the material came from, which claims were externally checked, which claims came from uploaded internal context, which came from transcripts, and which require owner validation before being treated as policy.

This package is not a vibes artifact. It uses a provenance register, claim-confidence labels, transcript handling rules, public verification notes, internal owner-validation flags, and evaluation receipts. Where a claim is not independently verified or owner-approved, it is labeled accordingly.

Source classes

Claim confidence labels

Transcript handling rule

Practitioner transcripts are used to extract operating patterns, not to establish policy. Where a transcript makes a factual claim, the claim is verified against public sources, labeled as transcript-derived, or excluded from authoritative guidance.

Claim validation register

Eval provenance rule

The three model evaluations validate artifact quality, audience fit, gaps, and distribution readiness. They do not validate internal policy, approve external tools, or prove every factual claim. They are used as review evidence, not as truth certificates.

Template Library and Source WorkbenchCopy MarkdownDownload .md

The Workbench is where concepts become reusable artifacts. Each pack is large enough to stand alone, maps back to a main section, and now includes card-level copy and download controls so teams can reuse the right artifact without scraping the entire manual.

The Source Workbench is a reuse surface, not a decorative footer. The main body teaches the concepts. This workbench provides copy-ready artifacts, owner/reviewer expectations, failure modes, and repo mappings. Tiny cards are intentionally bundled into larger packs so each item carries enough operational weight to be worth copying.

# Executive Reset Pack

## Opening statement
Stop building AI theater. Build capability.

Prompts, agents, skills, tools, and evals are components. Capability requires intent, source authority, context discipline, schemas, validation, observability, change control, sustainment, and measurable value.

## Leader approval stop rule
If the team cannot explain outcome, data boundary, source authority, schema, eval validity, human review model, telemetry, sustainment owner, and stop condition, approve discovery only. Do not approve broad pilot, production routing, autonomous execution, or business-process dependency.

## Questions leaders should ask
1. What business outcome changes?
2. What source is authoritative?
3. What must the AI never infer?
4. What is deterministic, what is AI-assisted, and what remains human-controlled?
5. What telemetry proves value and degradation?
6. Who owns maintenance after the demo?

# Capability Formation Pack

## Definition
An AI capability is a governed, repeatable, measurable operating pattern that uses approved models, tools, data, workflows, controls, human review, and sustainment ownership to produce a defined business outcome reliably over time.

## Readiness ladder
0 Idea. 1 Prompt artifact. 2 Reusable harness. 3 Structured workflow. 4 Eval-backed assistant. 5 Governed pilot. 6 Operational capability. 7 Scaled enterprise capability.

## Promotion gate rule
Do not promote Levels 3 to 6 by enthusiasm alone. Require evidence for schema validity, fixture coverage, reviewer calibration, approved data route, stop conditions, telemetry, runbook, incident path, support owner, and adoption proof before naming the next level.

## Intent validity gates
Problem clarity, outcome specificity, user fit, AI appropriateness, source feasibility, data permission, failure consequence, human accountability, and sustainment realism must be answered before implementation.

## Solution ideation rule
Compare no AI, deterministic rules, workflow automation, search/RAG, dashboard/report, chat assistant, agentic workflow, and integrated capability before choosing the agentic path.

# Governance and Routing Pack

## Bright-line rule
Tool access does not approve the use case, data class, retention behavior, logging posture, workflow impact, or business-process automation.

## Engagement modes
USE approved prebuilt capability within its boundary. BUILD personal or small-group productivity agents only within approved constraints. REQUEST business-process or reusable capability through governance.

## No-review logic
No review applies only when every low-risk condition is true. If any condition is false, route to governance.

## External tool warning
External commercial tools are learning and pattern references only unless explicitly approved for enterprise data and work.

# Context and Source Authority Pack

## Source precedence
Canonical documents govern service and process guidance. Structured records govern current state. Governed references provide context. Generated outputs are explanatory only. Stale or prohibited sources must be labeled and excluded from authority.

## Evidence states
Supported, not evidenced, conflicting evidence, requires confirmation, requires escalation, not applicable.

## Non-inference rule
The assistant must not infer approval status, data classification, GxP impact, ownership, production readiness, security control existence, or policy exceptions from silence.

# Schema and Contract Pack

## Required schemas
Input schema, output schema, evidence schema, decision-state schema, exception schema, telemetry event schema, override payload schema, and tool contract schema.

## Schema rule
If the team cannot define valid input and output shape, the capability is not ready for implementation.

## Example evidence fields
claim_id, source_id, source_type, evidence_state, confidence, excerpt, reviewer_action, override_reason, trace_id.

# Harness, Rubric, and Eval Pack

## Harness minimum fields
Objective, audience, inputs, source hierarchy, constraints, non-goals, output contract, allowed inference, stop conditions, validation method, and completion report.

## Eval validity checks
Construct, criterion, coverage, regression, risk, operational, reviewer reliability, and negative-control validity.

## Fixture starter set
Golden case, missing-evidence case, conflicting-source case, adversarial overreach case, ambiguous request case, regression case, and unsafe-action request.

# Practitioner Operations Pack

## Safe operating sequence
1. Q&A first. 2. Ask for a plan. 3. Review scope. 4. Allow controlled edits. 5. Run tests or schema checks. 6. Review diffs. 7. Capture evidence. 8. Commit only after human approval.

## Minimum feedback loops
Unit test, schema validation, static analysis, screenshot or output comparison where relevant, security scan, cost/loop limit, and human review.

## Synthetic lab entry point
Run the synthetic lab at `labs/synthetic-capability-lab/` when you need a safe repo-shaped example with schemas, source authority, fixtures, expected outputs, tests, and a validation receipt.

## External-tool boundary
Use public or synthetic data only unless the enterprise tool and data path are explicitly approved.

# Harness Lifecycle and Maintenance Pack

## Five maintenance checks
What is it eating? What can it reach? What is its job? What proof must it return? Is it still valuable?

## Pruning rule
Every tool increases action surface, ambiguity surface, permission surface, audit surface, cost surface, and maintenance burden. Tools must earn their place through observed value and controlled failure behavior.

## Model upgrade trigger
A stronger model can make old constraints too restrictive or old permissions too dangerous. Revalidate after model, tool, source, or workflow changes.

# Worked Example Pack

## Example A
Bad prompt to governed harness. Shows how a vague request becomes objective, source authority, output contract, rubric, eval fixture, and receipt.

## Example B
Business-process capability trace. Shows intent to telemetry and human decision.

## Example C
Lifecycle Lens MVP. Shows advisory-only, Microsoft-native, source-priority, structured-state, no-mutation posture.

## Example D
Tool pruning and maintenance. Shows how to remove tools that add more risk than value.

# Repo Bootstrap Pack

## Purpose
This scaffold is a reference structure for AI capability discipline artifacts. It is not a deployable product, final policy repository, or approved enterprise runtime.

## Top-level folders
docs, context, schemas, harnesses, rubrics, evals, tools, governance, operations, receipts.

## Rule
Every reusable artifact in the field manual should map to a file path or an explicit reason why it remains narrative-only.

# Source Provenance Pack

## Provenance rule
Say what was confirmed, against what source, at what confidence level, and what still requires owner validation.

## Required labels
Verified public source, corroborated, transcript-derived, internal-source supplied, owner validation required, derived recommendation, illustrative example, do not treat as policy.

## Eval rule
Model evals validate artifact quality and gap coverage. They do not certify factual truth or internal policy.