U27-S08 // Knowledge Readiness

PUBLIC_PACKAGE // FIELD_KIT

Knowledge Readiness classifies internal knowledge before it becomes AI memory, onboarding material, workflow automation context, agent handoff material, or public proof.

U27-S08
KNOWLEDGE READINESS

CLASS: SYSTEM
OPERATING_POSITION: 03/08
FUNCTION: Knowledge Status Classification + Handoff Safety Gate
REF_ID: U27-S08-KNOWLEDGE-READINESS

Release Status

SOURCE_STATUS: PUBLIC_PACKAGE ACCESS_STATUS: CLEARED_FOR_EXTERNAL_USE

This repository is an initial public Unit27 field kit.

It belongs between Context Engine and Handoff Engine in the Unit27 field-kit suite.

It answers one narrow question:

Which parts of this context are safe to teach, remember, hand off, automate, or act on?

Why Use It

Use Knowledge Readiness after context has been gathered and before a handoff is written.

It is useful when internal knowledge is stale, scattered, role-specific, source-anchored but not verified, disputed between sources, restricted to certain audiences, or risky to turn into action too early.

Example:

Problem: Context says "refunds over $500 require founder approval," but a newer support note says support leads can approve refunds up to $1,500.
Result: Knowledge Readiness marks the refund rule disputed and changes the handoff from "teach the refund rule" to "confirm current refund approval owner before training or automation."

System Position

Public suite position:

Stack Engine -> Context Engine -> Knowledge Readiness -> Handoff Engine -> Eval Bench -> Proof Ledger -> Boundary Engine -> u27-check

Knowledge Readiness sits after context packaging and before handoff generation.

It does not gather context. It does not write the handoff. It decides what the prepared context is allowed to become.

What It Does

The CLI writes:

1. u27/knowledge_readiness_manifest.json
2. u27/KNOWLEDGE_READINESS_PACKET.md
3. evals/proof_cases.json

The repo also includes release artifacts and boundary docs:

1. u27/HANDOFF_PACKET.md
2. u27/PROOF_PACKET.md
3. u27/BOUNDARY_REGISTER.md
4. evals/eval_cases.json

It is designed to feel like a status gate between context and handoff, not a memory system.

Readiness Statuses

Use the smallest status that is true.

Status	Meaning	Allowed Use
observed	Seen in notes, chat, research, or conversation, but not verified.	Discussion only.
source-anchored	Tied to a named source, file, transcript, repo, or live page.	Cautious summaries and retrieval briefs.
verified	Checked against current source material or owner confirmation.	Internal planning and reusable context.
role-ready	Safe to teach or reuse for a specific role or workflow.	Onboarding tracks and role guidance.
action-ready	Safe to drive a next action after normal approval gates.	Tasks, handoffs, and automations.
restricted	Useful but sensitive, confidential, or not for broad reuse.	Local-only guidance.
disputed	Conflicting sources or unresolved uncertainty exist.	No action without review.
expired	Previously useful, now stale or superseded.	Archive; do not reuse as current.

60-Second Start

Create a demo audit:

PYTHONPATH=src python3 -m knowledge_readiness.cli demo --root /tmp/knowledge-readiness-demo

Inspect the demo result:

PYTHONPATH=src python3 -m knowledge_readiness.cli inspect /tmp/knowledge-readiness-demo/u27/knowledge_readiness_manifest.json
cat /tmp/knowledge-readiness-demo/u27/KNOWLEDGE_READINESS_PACKET.md

Run the included sample:

PYTHONPATH=src python3 -m knowledge_readiness.cli audit examples/sample-project/knowledge_items.json --root /tmp/knowledge-readiness-sample

See the handoff delta in examples/sample-project/handoff-before-after.md.

Input Contract

knowledge-readiness audit expects a JSON file with a top-level items list.

Minimal item:

{
  "items": [
    {
      "id": "C-01",
      "claim": "Refunds over $500 require founder approval.",
      "source": "Old onboarding doc",
      "target_use": ["onboarding", "automation"],
      "conflicts_with": ["C-02"]
    }
  ]
}

Recognized item fields:

Field	Required	Purpose
id	No	Stable item label for packets and review.
claim	Yes	The knowledge claim being classified.
source	No	File, note, transcript, owner, repo, or live source anchor.
target_use	No	Intended use such as onboarding, handoff, automation, task, action, or public claim.
conflicts_with	No	Item ids, source names, or notes that make the claim disputed.
owner	No	Human owner or reviewer for role/action readiness.
verified	No	Marks the claim as checked against current source material or owner confirmation.
actionable	No	Marks the claim as safe to drive a next task after normal approval gates.
sensitive	No	Blocks broad reuse, automation, or public claims.
stale	No	Marks the claim expired until a current source or owner is found.
public_claim	No	Treats the item as restricted unless reviewed for public use.

Run the public-release checks:

PYTHONPATH=src python3 -m unittest discover -s tests
python3 scripts/verify_public_release.py

Then inspect the repo artifacts:

cat u27/KNOWLEDGE_READINESS_PACKET.md
cat u27/HANDOFF_PACKET.md
cat docs/validation-log.md

Current Evidence

Knowledge Readiness has been tested against:

• synthetic customer-success onboarding
• generic strategy handoff
• career-positioning handoff
• suite-inclusion decision
• outbound-message review
• source-of-truth update
• outreach-operations handoff
• pipeline rebuild handoff
• claim-discipline review
• correspondence-registry handoff

See docs/validation-log.md.

Claim Boundary

Safe:

Knowledge Readiness is a Unit27 field-kit layer for classifying internal knowledge before it becomes onboarding material, AI memory, workflow automation context, agent handoff material, or public proof.

Unsafe:

• "This solves AI memory."
• "This is a novel category with no adjacent work."
• "Unit27 invented governed memory."
• "This is an enterprise knowledge-governance platform."
• "This is market-validated or enterprise-ready."

See docs/claim-boundaries.md.

What It Does Not Do

Knowledge Readiness does not:

1. Store persistent memory
2. Build a RAG system
3. Replace Context Engine
4. Replace Handoff Engine
5. Replace Boundary Engine
6. Certify legal, security, compliance, or production truth
7. Publish a source as verified just because it exists
8. Turn package validation into market validation

Verification

PYTHONPATH=src python3 -m unittest discover -s tests
PYTHONPATH=src python3 -m knowledge_readiness.cli demo --root /tmp/knowledge-readiness-demo
PYTHONPATH=src python3 -m knowledge_readiness.cli inspect /tmp/knowledge-readiness-demo/u27/knowledge_readiness_manifest.json
python3 scripts/verify_public_release.py
python3 -m json.tool schemas/knowledge_readiness_manifest.schema.json
python3 -m json.tool u27/knowledge_readiness_manifest.json
python3 -m json.tool evals/eval_cases.json

Release Guardrails

For public use:

1. Keep the suite position as OPERATING_POSITION: 03/08.
2. Keep the structural class as U27-S08.
3. Run scripts/verify_public_release.py.
4. Confirm every public claim is listed in u27/BOUNDARY_REGISTER.md.
5. Confirm examples show handoff delta, not just labeling.
6. Do not claim novelty, solved memory, market validation, or enterprise governance.
7. Keep package validation separate from public proof.

License

MIT.