Shared Capability Foundations v0.1

Status: shared operating core candidate. Field guidance, not final policy.

1. 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.

2. Capability formation equation

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.

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.

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.

3. Canonical reusable primitives

4. Readiness and lane model

5. Source authority and evidence states

6. Non-inference and routing

Assistants, agents, reviewers using model output, and repo automation must not infer approval status, funding approval, capacity approval, 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, or support-load reduction.

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

7. Evaluation, review, and sustainment

8. Use rules for the playbook family

9. Future refinement candidates

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.