-
Notifications
You must be signed in to change notification settings - Fork 5
Skill Interface Contract
The Skill Interface Contract is the set of five non-removable requirements that any Claude Skill must satisfy when it declares FPCOS as its base layer. It is the binding agreement between the base OS and any domain application running on it.
Non-negotiable means: These requirements cannot be overridden by the operator, user instruction, token pressure, or "obvious question" reasoning. If a skill removes any of the five, it is not building on FPCOS — it is building something else and borrowing the name.
-- | -- | -- | -- 01 | Inherit Reality Anchor — declare Known / Inferred / Unknown before any claim | L0 | ❌ Never 02 | Apply Kalama10 as proof standard — domain expertise ≠ exemption | L1 | ❌ Never 03 | Use Ariya4 for problem framing — all 4 fields required before solution | L1 | ❌ Never 04 | Run Shadow Gate before final output — all 5 protocols | L4 | ❌ Never 05 | State confidence % and unknowns explicitly | L5 | ❌ Never
Add to any child skill's YAML frontmatter:
base_os: "first-principle-codex-os"
base_os_version: "1.0"
This declaration signals that the skill is bound by the Skill Interface Contract.
- Skill-Inheritance-Guide — Step-by-step build guide
- Anti-Patterns — Common contract violations and why they fail
- Extension-Rules — Full guide to what child skills may and may not do
- Child-Skills — Skills currently built on FPCOS
# Skill Interface Contract
[← Back to Home](Home)
The Skill Interface Contract is the set of five non-removable requirements that any Claude Skill must satisfy when it declares FPCOS as its base layer. It is the binding agreement between the base OS and any domain application running on it.
Non-negotiable means: These requirements cannot be overridden by the operator, user instruction, token pressure, or "obvious question" reasoning. If a skill removes any of the five, it is not building on FPCOS — it is building something else and borrowing the name.
| # | Contract | Layer | Removable? |
|---|---|---|---|
| 01 | Inherit Reality Anchor — declare Known / Inferred / Unknown before any claim | L0 | ❌ Never |
| 02 | Apply Kalama10 as proof standard — domain expertise ≠ exemption | L1 | ❌ Never |
| 03 | Use Ariya4 for problem framing — all 4 fields required before solution | L1 | ❌ Never |
| 04 | Run Shadow Gate before final output — all 5 protocols | L4 | ❌ Never |
| 05 | State confidence % and unknowns explicitly | L5 | ❌ Never |
Every skill built on FPCOS must declare the epistemic status of all inputs before reasoning proceeds. The format may be adapted for the domain, but the three categories (Known / Inferred / Unknown) are fixed.
Domain adaptation allowed:
- Finance: Known = verified price data / Inferred = model-based projection / Unknown = future conditions
- Medical: Known = confirmed diagnosis / Inferred = probable diagnosis / Unknown = untested conditions
- Coffee: Known = measured roast curve / Inferred = flavor projection / Unknown = cup result pre-brew
What is not allowed: Skipping the declaration because the input "seems obvious" or "is from a reliable source." Reliability of source does not change the epistemic status — it changes the confidence level, which is stated in the Inferred category.
Every claim used as a reasoning foundation must pass the 10-gate Kalama standard. Domain expertise narrows the prior — it does not eliminate verification.
Most commonly violated gate in domain skills: K7 (theory-fit). Domain experts are highly susceptible to accepting evidence that confirms their existing model. The Kalama10 requirement explicitly forces alternative models to be considered.
Domain adaptation allowed: Domain skills may add domain-specific evidence categories to each gate. What is not allowed: removing any gate, or adding a gate that substitutes for Kalama10.
All four fields of the problem frame must be completed before any solution is proposed. If Field 2 (Cause) cannot be completed, the problem has not been understood — do not proceed.
Domain adaptation allowed: Domain skills may rename the fields to domain-appropriate language as long as the logical structure is preserved:
- Problem = what is actually broken (not symptom)
- Cause = structural root cause (not proximate event)
- Cessation = specific falsifiable definition of done
- Path = least-friction route from Problem to Cessation
All 5 core protocols (Mirror, Inversion, Blind Spot, Interest Map, Meta-Void) run before any final output. Domain skills may add extensions after the core 5 — they may not replace or remove any of the core 5.
Output without Shadow Gate = INVALID. This is enforced at the architecture level: an output that lacks the Shadow Gate section is not a FPCOS output regardless of how many other layers ran.
Every output must include:
- CONFIDENCE as explicit percentage
- SHADOW VERDICT (CONSISTENT / FRAGILE / REBUILD)
- UNKNOWNS (specific, not generic — "none" is invalid)
- FAILURE COND (specific falsifiable condition that breaks the conclusion)
Domain adaptation allowed: Field names may be adapted. The four pieces of information are non-negotiable.
| Action | Allowed? |
|---|---|
| Add domain layers between L2 and L4 | ✅ Yes |
| Rename layers for domain context | ✅ Yes |
| Add Shadow Gate protocols after the core 5 | ✅ Yes |
| Add domain-specific Confidence Field sub-items | ✅ Yes |
| Remove L0, L1, L4, or L5 | ❌ Never |
| Bypass Kalama10 for "expert" claims | ❌ Never |
| Skip Ariya4 for "obvious" problems | ❌ Never |
| Output without Shadow Gate | ❌ Never |
| State "none" for Unknowns | ❌ Never |
| Remove core Shadow Gate protocols (1–5) | ❌ Never |
Add to any child skill's YAML frontmatter:
base_os: "first-principle-codex-os"
base_os_version: "1.0"This declaration signals that the skill is bound by the Skill Interface Contract.
- Skill-Inheritance-Guide — Step-by-step build guide
- Anti-Patterns — Common contract violations and why they fail
- Extension-Rules — Full guide to what child skills may and may not do
- Child-Skills — Skills currently built on FPCOS
[← Back to Home](Home)