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

Queue-based agent work states

Queue-based agent work can use common states when the states help owners route work without turning the queue into an approval system.

Queue state is not approval. Approval still requires the proper owner, evidence, and governance path.

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

Runtime-portable design does not imply runtime or tool equivalence. A governed capability can move across runtimes only when the same boundaries, inputs, outputs, validation, permissions, and evidence contracts are preserved.

These shared primitives do not imply policy approval, tool approval, data approval, production approval, autonomous-governance approval, model approval, vendor approval, security approval, legal approval, GxP approval, or enterprise deployment approval.

7. Evaluation, review, and sustainment

Runtime-portable assets

Durable capability assets include governed files, schemas, manifests, source maps, catalogs, receipts, decisions, validation fixtures, and authoritative source systems.

The governed workspace is the durable brain. The runtime is replaceable. Chat history, tool sessions, IDE state, and model memory can provide context, but they are not source authority.

Good AX includes clear file paths, manifests, receipts, tests, validators, schemas, stop conditions, issue links, ownership boundaries, and closeout expectations.

Procedure skill design standard

Procedure skills must define purpose, trigger, scope, required inputs, allowed outputs, evidence requirements, context exposure risk, owner, fixture coverage, stop conditions, review cadence, and retirement condition.

External pattern intake and verification

External pattern intake requires normalization, source identity, presenter or source credibility check, claim classification, sponsor and commercial incentive split, credibility scoring, safe reuse labels, unsafe reuse labels, and framework mapping.

External transcripts, demos, practitioner claims, vendor claims, and productivity anecdotes must not become doctrine without verification and owner approval.

Harness feedback loop

Accepted edits, overrides, rejects, and escalations must route to source issue, control issue, schema gap, fixture gap, prompt or instruction gap, reviewer calibration, or no-change decision.

8. Use rules for the playbook family

9. What not to do

Do not treat readiness scores as approval. Do not promote any package to policy without source-owner validation. Do not let the assistant, agent, Jira story, model, or vendor become the decision authority.

Do not treat runtime portability as approval to use a different model, vendor, tool, data class, security posture, legal posture, GxP posture, production runtime, or enterprise deployment path.

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