# Shared Capability Foundations v0.1

Status: shared operating core candidate  
Date: 2026-06-17  
Boundary: field guidance, not final policy

## 1. Why shared foundations matter

Shared Capability Foundations gives the AI Capability Playbook a common operating vocabulary. It keeps doctrine, build-readiness work, reference implementations, and prompt packs from using different terms for the same governance and capability concepts.

Use it before a review, build decision, prompt-pack rendering, or implementation pattern discussion where terms such as source authority, evidence state, non-inference, eval, review, telemetry, or sustainment need to mean the same thing.

## 2. Core thesis

A capability is not created by model access, a prompt, an agent, a demo, a Jira epic, or a clever assistant. A capability exists only when intent, authority, evidence, workflow, ownership, governance, telemetry, support, sustainment, and measurable value are credible enough to survive real work.

## 3. Capability formation equation

```text
Governed Capability =
  Clear Intent
+ Approved Data Path
+ Source Authority
+ Workflow Fit
+ Schema Contracts
+ Harnesses
+ Rubrics
+ Valid Evals
+ Human Review
+ Tool Permissions
+ Observability
+ Governance Routing
+ Capacity and TCO Discipline
+ Sustainment Ownership
+ Measured Business Outcome
+ Stop or Retirement Criteria
```

Missing a major term does not make the idea useless. It means the idea is still discovery, sandbox, feasibility check, or bounded proof. Do not call it operational until the missing terms are resolved or explicitly accepted as limits.

### 3.1 Business outcome and value-line model

Value must be classified before it is judged. Start by naming the primary value class, then ask whether it clears the current acceptance threshold.

| Value class | Meaning |
|---|---|
| Direct savings | Hard OPEX or CAPEX reduction visible to the accountable budget owner. |
| Indirect savings | Savings realized by another team, process, workstream, or downstream function. |
| Avoided cost | Spend, labor, tooling, audit, remediation, incident, or rework cost avoided. |
| Risk reduction | Reduced compliance, operational, cyber, quality, delivery, or resilience exposure. |
| Capacity release | Human time freed for higher-value work or reduced backlog pressure. |
| Quality or rework reduction | Fewer defects, escalations, corrections, review loops, failed handoffs, or repeat work. |
| Cross-workstream value | Benefit that accrues outside the proposing or funding team. |

**Outcome Acceptance Line** means the minimum value class and evidence threshold a decision owner accepts for the current business climate, funding lane, or review context.

A proposal can create real value and still fall below the acceptance line if the wrong owner benefits, the evidence is weak, or the current mandate requires direct savings.

Use owner terms only where they clarify accountability: decision owner approves the work, budget owner owns the impacted budget, benefiting owner receives the measurable benefit, and evidence owner proves the value claim.

All value classes matter, but they do not matter equally in every business climate. When management is under an operating-expense reduction mandate, direct savings from the accountable operational budget may be the only value class that materially changes the decision. Indirect savings, avoided cost, risk reduction, capacity release, quality improvement, and cross-workstream value may still be real, but they may not clear the line without sponsorship, exception, or a different priority signal.

## 4. Canonical reusable primitives

| Primitive | Canonical definition | Primary users |
|---|---|---|
| Capability | A governed operating ability with intent, evidence, workflow, ownership, controls, telemetry, sustainment, and measurable outcome. | Leaders, architects, service owners, builders. |
| Sandbox | Low-risk personal or local exploration with no sensitive data, users, recurring team use, operational reliance, service-stack dependency, or meaningful shared capacity. | Engineers, practitioners, managers. |
| Feasibility check | A short time-boxed investigation to answer one specific unknown before more work is justified. | Managers, engineers, product/service owners. |
| Preflight | A lightweight decision checkpoint before meaningful capacity, contractor effort, Jira epic, service-stack work, recurring use, or governance-sensitive activity begins. | WESS leadership, service owners, development leads. |
| Preflight-approved proof | A bounded build or test authorized by preflight to validate feasibility, value, risk, and support assumptions. | Builders, product owners, service owners. |
| Operationalized capability | A tool, assistant, automation, workflow, dashboard, or service accepted into the operating model with owner, support, sustainment, governance path, telemetry, and stop criteria. | Service owners, operations, governance. |
| Source authority | The ranked status of evidence sources, including canonical, governed reference, submission evidence, derived analysis, historical, stale, and prohibited. | Architects, reviewers, AI systems, governance. |
| Evidence state | The status of a claim relative to available evidence: supported, not evidenced, conflicting evidence, requires confirmation, requires escalation, or not applicable. | Assistants, reviewers, auditors. |
| Non-inference | A rule preventing a model, assistant, or workflow from silently deciding approval, classification, source authority, funding, operational readiness, or other governed facts. | AI builders, reviewers, governance owners. |
| Human override | A captured reviewer action that accepts, edits, rejects, or overrides assistant output with rationale and evidence or judgment basis. | Reviewers, product owners, auditors. |
| Fixture | A test case used to validate expected assistant behavior across golden, incomplete, conflicting, adversarial, ambiguous, restricted, and regression scenarios. | Builders, validators, governance reviewers. |
| Stop condition | A defined trigger to stop, park, quarantine, remediate, narrow, rebuild, or retire a proof or operationalized capability. | Owners, leaders, reviewers. |

## 5. Readiness and lane model

| Universal readiness | AI Capability Discipline equivalent | MLL WESS lane equivalent | Enterprise Architecture Review Assistant equivalent |
|---|---|---|---|
| Idea | Level 0: Idea | Sandbox | Concept or intake shaping |
| Prompt or local prototype | Level 1: Prompt artifact | Sandbox | Manual exploration or draft prompt |
| Reusable harness | Level 2: Reusable harness | Time-boxed feasibility check | Manual harness rehearsal |
| Structured workflow | Level 3: Structured workflow | Preflight candidate | Evidence loop design |
| Eval-backed assistant | Level 4: Eval-backed assistant | Preflight-approved proof | Controlled implementation proof |
| Governed pilot | Level 5: Governed pilot | Preflight-approved proof or early operationalization candidate | Small reviewer pilot with approved data path |
| Operational capability | Level 6: Operational capability | Operationalized capability | Supported review assistant |
| Scaled enterprise capability | Level 7: Scaled enterprise capability | High-control operationalized capability | Enterprise integrated review capability |

## 6. Source authority model

| Source class | Can support findings? | Required handling |
|---|---:|---|
| Canonical | Yes | Cite source, owner, and version. |
| Governed reference | Yes, with context | Cite source and explain limitation. |
| Submission evidence | Yes for what was submitted | Mark as submission evidence, not policy. |
| Structured source of truth | Yes for current state | Use for current ownership, status, lifecycle, and workflow facts. |
| Derived analysis | No by itself | Must cite underlying evidence. |
| Historical | Conditional | Use only with date, version, and applicability check. |
| Stale | No for current decisions | Flag as stale or superseded. |
| Prohibited | No | Do not use as evidence. |

## 7. Evidence states

| State | Meaning | Required behavior |
|---|---|---|
| supported | Claim is backed by allowed evidence. | Cite or reference evidence. |
| not_evidenced | Required evidence is missing. | Do not infer. Request evidence or block promotion. |
| conflicting_evidence | Sources disagree. | Route to owner or human confirmation. |
| requires_confirmation | A qualified owner must confirm. | Keep unresolved until confirmed. |
| requires_escalation | Governance or management path must decide. | Route before build, promotion, or operational use. |
| not_applicable | Control does not apply based on documented facts. | State basis. |

## 8. Non-inference and routing

Assistants, agents, reviewers using model output, and repo automation must not infer approval status, funding approval, capacity approval, contractor availability, product ownership, sustainment ownership, source authority, data classification, privacy posture, GxP or quality impact, architecture clearance, technology approval status, production readiness, operational readiness, exception approval, Jira readiness, value realization, support-load reduction, or OPEX reduction.

If evidence is absent, use an explicit unresolved state such as `not_evidenced`, `requires_confirmation`, `requires_approval`, `requires_routing`, `blocked`, or `not_applicable`.

| Route before build or promotion when work touches | Examples |
|---|---|
| Security, ISRM, privacy, legal, TQ, or quality | Identity, secrets, personal data, GxP, validation, retention, audit posture, or regulated-process impact. |
| Platform, architecture, service owner, or operations | Copilot Studio, Azure, AWS, APIs, enterprise connectors, source-system dependency, endpoint workflows, support process, or monitoring. |
| Management, capacity, or agent scope | Budget impact, contractor consumption, priority tradeoff, shared agents, scheduled flows, publication to Teams or Copilot, or enterprise audience. |

## 9. Evaluation, review, and sustainment

| Control area | Minimum expectation |
|---|---|
| Fixture discipline | Test golden, incomplete, conflicting, adversarial, ambiguous, restricted, possible GxP, missing-security, non-AI alternative, and regression cases where relevant. |
| Human review | Reviewer has authority, evidence visibility, time, clear states, captured rationale, traceable decisions, and feedback into prompts, controls, schemas, fixtures, and source authority. |
| Capacity and TCO | Estimate owner time, technical lead time, employee and contractor effort, operations, documentation, governance review, recurring sustainment, platform cost, and opportunity cost. |
| Sustainment class | Classify as disposable, best-effort, team-supported, service-supported, or high-control. |
| Retirement trigger | Retire, narrow, rebuild, or quarantine when source authority cannot be maintained, workflow changes beyond harness design, review burden exceeds value, false-negative risk appears, permissions cannot be governed, users ignore output, or a better platform capability exists. |

## 10. Artifact pairing rule

Do not force one artifact to serve every audience badly.

| Human-readable artifact | Machine-readable counterpart |
|---|---|
| Product brief | Manifest and decision records |
| Governance routing guide | Schema fields, routing catalog, controls |
| Non-inference rules | Agent work modes, schema enums, validation tests |
| Evidence requirements | Review output schema and citation requirements |
| Evaluation strategy | Fixture plan and expected outputs |
| Human review workflow | Decision and override schema |
| Observability guide | Trace, event, metric, cost, and override telemetry fields |
| TCO model | Cost telemetry and value-tracking fields |

## 11. Use rules for the playbook family

| Package | How to use the shared foundations |
|---|---|
| AI Capability Discipline | Reference the shared foundations as common doctrine and vocabulary while keeping teaching examples broad. |
| MLL WESS Development Commitment and Build-Readiness Framework | Use the shared foundations as the discipline layer, then add WESS-specific decision rights, capacity rules, and preflight triggers. |
| Enterprise Architecture Review Assistant | Use the shared foundations as the architecture discipline layer, then add EA-specific source authority, controls, evidence states, reviewer workflow, and platform path. |
| Prompt Packs | Use the shared foundations to keep generated or rendered explanations aligned with playbook terms and policy boundaries. |

## 12. What not to do

Do not merge all playbook packages into one mega-document.

Do not let each package independently redefine shared terms.

Do not treat readiness scores as approval.

Do not promote any package to policy without source-owner validation.

Do not turn field guidance into a bureaucratic wall around sandbox exploration.

Do not let the assistant, agent, Jira story, model, or vendor become the decision authority.

## 13. Future refinement candidates

The previous public page carried a raw planning table. That backlog-like content has been reframed here as future refinement candidates so it does not interrupt the public reader flow or imply approved roadmap scope.

Useful future refinements include field-tested examples, a compact glossary, stronger evidence-state alignment checks, practical WESS checklists, a teaching module version of AI Capability Discipline, a source-owner validation receipt model, and adoption telemetry. These remain candidates until owner validation and issue-level prioritization confirm scope.