@kungfu-tech/kfd 1.0.0-alpha.19 → 1.0.0-alpha.20

package/decisions/{kfd-1.md → KFD-1.md}

@@ -44,8 +44,10 @@ when either holds:
 - **(b) Cross-time dependency** — its outputs remain depended on after the run
   (persisted data, audit evidence, replayable records).
 
-Each entry carries a stable kebab-case ID. Registers live in each repository's
-versioning document and are the input to every classification below.
+Each entry carries a stable kebab-case ID. A surface may be
+`integration-time`, `cross-time`, or both. Registers live in each repository's
+contract-world metadata or versioning document and are the input to every
+classification below.
 
 ## Concrete case: config contracts
 
@@ -61,21 +63,44 @@ steps, and the final product must consume the same contract mechanism. It is
 not enough for the packaged artifact to be internally consistent if the
 developer path used a different, driftable config source.
 
-## The decision procedure
+## The compatibility impact core
 
-Classify the actual diff against the register; the highest match wins:
+Classify the actual diff against the register; the strongest match wins:
 
 | # | Condition | Verdict |
 |---|---|---|
-| 1 | **Breaks** any registered surface (removal, semantic change, layout change, incompatible rename — a semantic change counts as breakage even when shapes are unchanged: changed defaults, changed channel meaning, a newly required field) | **major** |
-| 2 | **Additively evolves** a registered surface, or **adds** a surface consumers will weld to | **minor** (register the new surface at the same time) |
-| 3 | Touches no registered surface | **patch** — regardless of how large the feature is |
-| 4 | **Cannot be classified** | **Do not guess.** The register is deficient: fix the register first (a maintainer decision), then reclassify |
+| 1 | **Breaks** any registered surface (removal, semantic change, layout change, incompatible rename — a semantic change counts as breakage even when shapes are unchanged: changed defaults, changed channel meaning, a newly required field) | **breaking impact** |
+| 2 | **Additively evolves** a registered surface, or **adds** a surface consumers will weld to | **additive impact** (register the new surface at the same time) |
+| 3 | Touches no registered surface | **no registered-surface impact** — regardless of how large the implementation change is |
+| 4 | **Cannot be classified** | **unclassifiable impact. Do not guess.** The register is deficient: fix the register first (a maintainer decision), then reclassify |
 
 Rule 4 is the safety valve: it forces the irreducible judgment (what counts as
 a welded surface) to a maintainer instead of letting a change silently pick
 the convenient answer.
 
+These four impact classes are the KFD-1 core. They are not inherently release
+version numbers. A product must project them into the control action that
+matches its domain: version line movement, config migration, ABI epoch, API
+namespace, release gate, runtime compatibility bridge, or user workflow gate.
+
+## Release versioning projection
+
+For release versioning, the compatibility impact core projects to semver:
+
+| Compatibility impact | Release verdict |
+|---|---|
+| breaking impact | **major** |
+| additive impact | **minor** |
+| no registered-surface impact | **patch** |
+| unclassifiable impact | **block release; fix the register first** |
+
+This projection is the first implementation case, not the whole principle.
+Other domains must keep the same impact core while choosing their own action:
+config contracts may require a migration bridge or rejected old config, ABIs
+may require a new soname or ABI epoch, APIs may require a namespace or endpoint
+compatibility boundary, and agent/UI surfaces may require explicit workflow or
+command migration.
+
 ## Constraint clauses
 
 - **Reverse prohibition.** A line must not be opened for feature volume,
@@ -87,7 +112,8 @@ the convenient answer.
   self-archivable inputs, and no hard coupling to a maintainer-operated
   service.
 - **Decision time.** The verdict is checked against the final diff before the
-  promotion into the alpha channel; planning-time classification is only a
+  action gate that depends on it; for releases this is checked before
+  promotion into the alpha channel. Planning-time classification is only a
   prediction.
 - **Major dignity.** A major release communicates exactly one thing: something
   you welded to broke and you must re-audit. An empty major — one that breaks
@@ -118,9 +144,11 @@ the convenient answer.
 
 ## The decision log
 
-Line openings (minor/major), register changes, and deprecations must be
-recorded in the repository's versioning document; patches stay silent —
-silence is itself the signal that no registered surface was touched.
+Line openings (minor/major), register changes, deprecations, and other
+compatibility-impact decisions must be recorded in the repository's
+contract-world or versioning document. Release patches stay silent — silence
+is itself the signal that no registered surface was touched in the release
+projection.
 
 One markdown table row per event, newest first:
 

package/decisions/{kfd-2.md → KFD-2.md}

@@ -23,7 +23,9 @@ KFDs can be principles or procedures:
 
 This KFD is a principle. KFD-1 is the procedure that keeps the fact sources
 under this principle from drifting. KFD-3 is the principle that governs how
-humans and agents cooperate once facts and trust are visible.
+humans and agents cooperate once facts and trust are visible. KFD-4 is a
+procedure whose observer-perspective claims can also be assessed under this
+principle.
 
 ## Foundation role
 
@@ -38,6 +40,10 @@ before the product has made the relevant facts inspectable. KFD-1 protects the
 non-drifting fact source those claims stand on. KFD-3 protects the relationship
 with the human or agent who must understand and act on those facts.
 
+KFD-2 is not a checker for only one other KFD. It is the generic trust
+adjudication layer for any KFD claim, product claim, artifact claim, control
+surface claim, or release claim that asks a human or agent to rely on it.
+
 ## Principle
 
 When a kungfu-systems product represents work or control, its default path
@@ -71,6 +77,27 @@ leaves enough evidence for later review.
 - Hosted or cloud convenience may add synchronization, storage, compute, and
   collaboration, but it must not become the only place where the truth exists.
 
+## Generic trust assessment model
+
+Every KFD-2 trust assessment starts from a claim. The claim may be about a
+release, but it may also be about a contract world, a collaboration interface,
+an observer perspective, a config surface, an API, an ABI, a GUI surface, a
+runtime fact, documentation, or another product surface.
+
+A claim is trustable only when the assessment can state:
+
+- what the claim is about;
+- which facts the claim binds to;
+- which evidence was checked;
+- what can be machine verified;
+- what remains a residual risk;
+- who owns source facts, verification, and the trust decision;
+- whether the result is pass, warning, fail, or unverifiable.
+
+This model is intentionally general. KFD-1, KFD-3, KFD-4, and future KFDs can
+provide claims that KFD-2 assesses. Release trust passports are one projection
+of this model, not the model itself.
+
 ## What it does not require
 
 - It does not require every product to be a journal engine or runtime ledger.
@@ -111,12 +138,18 @@ README says so. It publishes inspectable facts: decision documents,
 metadata, and conformance checks.
 
 KFD-2 also owns the trust taxonomy used by release claims, release trust
-passports, and KFD-3 witnesses. Unknown residual-risk or trust-downgrade values
-fail validation until KFD records them in
-`schemas/kfd-2/trust-taxonomy.schema.json`. When an agent needs a new value,
+passports, KFD-3 witnesses, and generic trust assessments. Unknown
+residual-risk or trust-downgrade values fail validation until KFD records them
+in `schemas/kfd-2/trust-taxonomy.schema.json`. When an agent needs a new value,
 the declared extension path is to open an issue in
 `https://github.com/kungfu-systems/kfd` rather than inventing a private value.
 
+The package dogfoods this model through
+`.buildchain/kfd-2/kfd-foundation.trust-claims.json` and
+`.buildchain/kfd-2/kfd-foundation.trust-assessment.json`. Those files assess
+KFD-1's contract-world claim, KFD-3's collaboration-interface claim, and KFD-4's
+observer-perspective claim through the same KFD-2 structure.
+
 ## Adopters
 
 Each adopting repository cites this KFD when designing or changing a fact

package/decisions/{kfd-3.md → KFD-3.md}

@@ -97,6 +97,13 @@ human-readable facts wherever possible. A capable agent should be able to learn
 the product's value, and why that value can be trusted, by inspecting the
 product's own facts and commands.
 
+Trusted value is therefore not only a product promise or persuasive sentence.
+A collaboration interface should bind important value claims to explicit value
+evidence: the facts that make the value claim inspectable, the artifacts or
+checks that prove those facts are present, and the KFD-2 trust assessment or
+residual-risk state that tells participants how much weight to place on the
+claim.
+
 ### 3. Use constraints as transparent safety, not hidden control
 
 Hard constraints are legitimate when they protect users, agents, work products,
@@ -165,6 +172,12 @@ KFD-1 protects the fact-source layer. KFD-2 protects the trust layer. KFD-3
 protects the relationship with the intelligent participant who must decide
 whether the offered value is trustworthy enough to walk that path.
 
+In machine-readable profiles, this means KFD-3 collaboration interfaces should
+not merely list surfaces and constraints. They should also declare value
+evidence that can be evaluated through the KFD-2 trust model. KFD-2 can then
+say which parts are machine-checkable, which parts remain semantic residual
+risk, and what an agent should do next.
+
 ## Implementation case: the KFD package
 
 The `@kungfu-tech/kfd` npm package is a self-proof case for this principle.
@@ -172,7 +185,10 @@ Its README gives humans and agents the same quickstart path. `standards.json`
 gives stable standard identity, schema IDs, and concept names. The KFD-3
 schemas define collaboration interfaces, witnesses, and extension requests, so
 an agent can discover both the valid interface and the standard path for asking
-to extend it.
+to extend it. The KFD-3 collaboration interface also declares value evidence
+that points to KFD-owned facts, package surfaces, and the KFD-2 generic trust
+assessment, so an agent can inspect why KFD's claimed value is trustable before
+cooperating.
 
 For example, if an agent needs a KFD-2 trust-taxonomy value that does not
 exist, the KFD-3 collaboration path is not hidden maintainer pressure or local

package/docs/KFD-1-usage.md

@@ -0,0 +1,37 @@
+# KFD-1 Implementation Notes
+
+KFD-1 defines the fact-source rule: facts must not drift. This page is the
+package implementation note for machine consumers and release systems. The
+authoritative decision text remains `decisions/KFD-1.md`.
+
+## Package Surfaces
+
+The KFD package implements KFD-1 through a declared contract world:
+
+- `standards.json#/standards/kfd-1/surfaceRegister` is the package-owned
+  surface register.
+- `schemas/kfd-1/contract-world.schema.json` defines the contract-world schema.
+- `schemas/kfd-1/witness.schema.json` defines the witness schema.
+- `.buildchain/kfd-1/contract-world.witness.json` projects registered surfaces,
+  source hashes, artifact hashes, surface classes, and impact projections.
+- `scripts/check.mjs` verifies the register, schema enums, witness hashes, and
+  surface projection.
+
+## Compatibility Impact Core
+
+KFD-1 uses four generic compatibility-impact classes:
+
+- `breaking`
+- `additive`
+- `none`
+- `unclassifiable`
+
+Release versioning is only one projection of those classes. Other domains can
+project the same core into config migration, ABI epochs, API namespaces,
+runtime compatibility bridges, or workflow gates.
+
+## Dogfood Role
+
+This package uses KFD-1 on itself. New public package surfaces should be added
+to `standards.json#/standards/kfd-1/surfaceRegister`, then projected into the
+KFD-1 witness by `node scripts/update-kfd-1-witness.mjs`.

package/docs/KFD-2-usage.md

@@ -0,0 +1,123 @@
+# KFD-2 Trust Assessment Metadata
+
+KFD-2 says that trust must start from inspectable facts and responsibility
+state. A product must not ask users or agents to trust load-bearing claims only
+because they appear in prose, changelogs, repository history, generated UI, or
+maintainer reputation.
+
+This package defines KFD-owned machine interfaces for the generic trust model:
+
+- `schemas/kfd-2/trust-taxonomy.schema.json`: the KFD-owned taxonomy for
+  residual-risk types, trust impact, machine provability, agent actions, and
+  downgrade reasons.
+- `schemas/kfd-2/trust-claims.schema.json`: the generic claim input shape for
+  KFD-2 assessment. Claims may target KFD standards, contract worlds,
+  collaboration interfaces, observer perspectives, releases, config, APIs,
+  ABIs, runtime facts, documentation, or other product surfaces.
+- `schemas/kfd-2/trust-assessment.schema.json`: the generic assessment output
+  shape that records result, checked facts, evidence, audit boundary,
+  responsibility, residual risk, and downgrade reasons.
+- `schemas/kfd-2/release-claims.schema.json`: the product's declared public
+  release claims, as a release-specific projection.
+- `schemas/kfd-2/release-trust-passport.schema.json`: the verifier's result
+  after auditing release claims against evidence.
+
+The generic flow is:
+
+```text
+trust claims -> evidence audit -> trust assessment -> product or release gate
+```
+
+The intended Buildchain flow is:
+
+```text
+release claims -> evidence audit -> release trust passport -> release passport
+```
+
+Release trust passports are one projection of KFD-2, not the whole KFD-2 model.
+Each claim should declare the statement being made, the subject of the claim,
+the facts it binds to, machine-readable evidence, the audit boundary, residual
+risk, and responsibility state. A trust assessment or release trust passport
+then records whether each claim is bound to evidence, which evidence was
+checked, what the result was, and who owns the decision.
+
+## Generic Trust Claims
+
+The generic claim model exists so KFD-2 can assess KFD-1, KFD-3, KFD-4, and
+future KFDs through one structure instead of inventing a new evaluator for each
+standard.
+
+A generic claim identifies:
+
+- `subject`: what the claim is about, such as `contract-world`,
+  `collaboration-interface`, `observer-perspective`, `release`, `config`,
+  `api`, `abi`, `gui-surface`, or `runtime-fact`;
+- `facts`: the inspectable fact sources the claim binds to;
+- `evidence`: the files, schemas, witnesses, commands, artifacts, URLs, or
+  manual-review records used to evaluate the claim;
+- `auditBoundary`: what the assessment covers and whether the surface is
+  closed-world, declared-open, sampled, or manual;
+- `responsibility`: who owns source facts, verification, and the decision;
+- `residualRisk`: KFD-2 taxonomy values for what remains unproved.
+
+The KFD package dogfoods this through:
+
+```text
+.buildchain/kfd-2/kfd-foundation.trust-claims.json
+.buildchain/kfd-2/kfd-foundation.trust-assessment.json
+```
+
+Those files assess KFD-1's contract-world claim, KFD-3's
+collaboration-interface claim, and KFD-4's observer-perspective claim. KFD-3
+currently receives a warning result because its machine-checkable interface
+still carries natural-language semantic residual risk.
+
+## Trust Taxonomy
+
+KFD-2 owns the vocabulary for residual risks and trust downgrades. A product,
+release tool, or agent must not invent new residual-risk values locally and
+still claim KFD-2 conformance. Unknown values fail schema validation.
+
+The current taxonomy is published in
+`schemas/kfd-2/trust-taxonomy.schema.json`. It defines:
+
+- `riskType`: what kind of trust gap remains;
+- `trustImpact`: whether the gap is informational, downgraded, failing, or
+  unverifiable;
+- `machineProvability`: whether the gap can be fully proved by machine;
+- `agentAction`: what an agent should do next;
+- `downgradeReason`: how a verifier maps residual risk into a release trust
+  result.
+
+If an agent needs a KFD-2 value that is not present, the standard extension
+path is to open an issue in the KFD repository:
+
+```text
+https://github.com/kungfu-systems/kfd/issues/new?title=KFD-2%20trust%20taxonomy%20extension%20request
+```
+
+The issue should state the missing value, the field it belongs to, the product
+or release scenario that needs it, and why existing values cannot express the
+case. Until KFD accepts the new value into the taxonomy schema, consumers
+should treat the value as invalid rather than as a soft warning.
+
+## Interface Versioning
+
+KFD package semver is only the distribution version. It is not the version of a
+KFD-owned machine interface.
+
+Every KFD-owned machine interface uses:
+
+- `schemaVersion`: the interface version consumed by tools.
+- `contract`: the stable contract name, such as `kfd-2-release-claims`.
+- `$id`: the canonical schema URL for the current stable interface.
+
+Compatible additions may keep `schemaVersion: 1`. A change that alters required
+fields, field semantics, verification meaning, audit boundary semantics, or
+responsibility semantics must not silently reuse the same interface contract.
+It must introduce a new interface version or, when the standard itself changes,
+a new KFD decision or amendment path.
+
+The same rule applies to KFD-1 and KFD-3 schemas. Their current schemas already
+carry `schemaVersion: 1` and a `contract` value; this document makes the
+evolution rule explicit across the KFD package.

package/docs/{kfd-3-collaboration-interface.md → KFD-3-usage.md}

@@ -32,6 +32,8 @@ A product collaboration interface should identify:
   interface;
 - participant-visible surfaces, such as CLI commands, JSON APIs, manuals,
   skills, GUI routes, envelopes, packages, or protocols;
+- value evidence that binds important participant-facing value claims to facts,
+  artifacts, checks, trust assessments, and residual-risk state;
 - visible constraints, including what is restricted, why, and where review or
   escalation happens;
 - choice paths that let participants choose or decline safe cooperation modes;
@@ -44,6 +46,25 @@ closed-world proof reports reachable entrypoints, classified entrypoints, and
 an empty `unclassifiedEntrypoints` list. This prevents a product from exposing
 a participant-facing or callable backdoor API outside the declared interface.
 
+## Value Evidence
+
+KFD-3 does not treat value as a marketing claim. A collaboration interface
+should state the value a participant is being asked to trust, then point to the
+facts and evidence that make that value inspectable.
+
+Each `valueEvidence` entry should identify:
+
+- the value claim;
+- the participants who depend on it;
+- the fact artifacts that define the claim;
+- the evidence artifacts or checks that show those facts are present;
+- a KFD-2 trust assessment or residual-risk state when the claim cannot be
+  exhaustively proved by machine.
+
+This is the engineering bridge between KFD-2 and KFD-3. KFD-2 explains how
+trust is assessed from facts. KFD-3 explains how that assessed value is exposed
+to participants before cooperation is requested.
+
 ## Product profile boundary
 
 Concrete product profiles may add their own contracts, registry fields, command

package/docs/KFD-4-usage.md

@@ -0,0 +1,31 @@
+# KFD-4 Implementation Notes
+
+KFD-4 defines the observer-perspective rule: timelines must declare their
+observer. This page is the package implementation note for machine consumers
+and products that show perspective-bearing timelines. The authoritative
+decision text remains `decisions/KFD-4.md`.
+
+## Package Surface
+
+The KFD package implements KFD-4 through:
+
+- `decisions/KFD-4.md`: the authoritative procedure text.
+- `schemas/kfd-4/observer-perspective.schema.json`: the KFD-owned schema for
+  observer-relative timeline views.
+- `standards.json#/standards/kfd-4`: metadata that exposes the schema ID, schema
+  path, interface contract, and concept names.
+- `scripts/check.mjs`: verification that KFD-4 metadata and schema remain
+  wired into the package.
+
+## When To Use The Gate
+
+Use KFD-4 when a product surface represents time, history, replay, sync,
+ordering, or mixed-source work state. A product that does not present a
+perspective-bearing timeline does not need a KFD-4 gate.
+
+## Trust Relation
+
+KFD-4 claims can be assessed by KFD-2. The KFD package does this through
+`.buildchain/kfd-2/kfd-foundation.trust-claims.json` and
+`.buildchain/kfd-2/kfd-foundation.trust-assessment.json`, where KFD-4 is
+assessed as an `observer-perspective` subject.

package/docs/MAP.md

@@ -6,24 +6,30 @@
 | What is the KFD-1/2/3 foundation triad? | [`../README.md`](../README.md#foundation-triad) |
 | What worldview structure does the foundation triad express? | [`../README.md`](../README.md#foundation-model) |
 | What practice guidelines are derived from the foundation triad? | [`../README.md`](../README.md#practice-guidelines) |
-| How should a product show timeline order from a declared perspective? | [KFD-4](../decisions/kfd-4.md) |
+| How should a product show timeline order from a declared perspective? | [KFD-4](../decisions/KFD-4.md) |
 | What schema should products use for KFD-4 observer-relative timeline views? | [`../schemas/kfd-4/observer-perspective.schema.json`](../schemas/kfd-4/observer-perspective.schema.json) |
+| What are the package implementation notes for KFD-1? | [`KFD-1-usage.md`](KFD-1-usage.md) |
+| What are the package implementation notes for KFD-2? | [`KFD-2-usage.md`](KFD-2-usage.md) |
+| What are the package implementation notes for KFD-3? | [`KFD-3-usage.md`](KFD-3-usage.md) |
+| What are the package implementation notes for KFD-4? | [`KFD-4-usage.md`](KFD-4-usage.md) |
 | How should an agent quickly understand this package? | [`../README.md`](../README.md#agent-quickstart) |
 | What is the concrete self-proof case for KFD-1/2/3/4? | [`../README.md`](../README.md#product-proof-path) and the implementation case in each KFD |
 | Where is the public KFD fact source? | [`../README.md`](../README.md#decision-metadata) and [`../site/kfd-site.json`](../site/kfd-site.json) decision metadata |
 | What does Apache-2.0 cover, and what remains official/trademark-bound? | [`../TRADEMARKS.md`](../TRADEMARKS.md) |
 | What should a site renderer consume to render `kfd.libkungfu.dev`? | [`../site/kfd-site.json`](../site/kfd-site.json) |
-| What is the top-level product accountability principle? | [KFD-2](../decisions/kfd-2.md) |
-| What stance should products take toward humans and agents as reasoning participants? | [KFD-3](../decisions/kfd-3.md) |
-| What schema should products use for KFD-3 participant-facing collaboration interfaces? | [`kfd-3-collaboration-interface.md`](kfd-3-collaboration-interface.md) |
-| What should an agent do when a needed KFD-2 trust taxonomy value is missing? | [`kfd-2-release-trust.md`](kfd-2-release-trust.md#trust-taxonomy) — open a KFD GitHub issue |
+| How should a site map decision pages to usage subpages? | [`../site/kfd-site.json`](../site/kfd-site.json) — `decisionPages.usagePages` maps `/N` to `/N/usage` |
+| What is the top-level product accountability principle? | [KFD-2](../decisions/KFD-2.md) |
+| What stance should products take toward humans and agents as reasoning participants? | [KFD-3](../decisions/KFD-3.md) |
+| What schema should products use for KFD-3 participant-facing collaboration interfaces? | [`KFD-3-usage.md`](KFD-3-usage.md) |
+| What schema should a product or agent use for generic KFD-2 trust assessment? | [`KFD-2-usage.md`](KFD-2-usage.md#generic-trust-claims) |
+| What should an agent do when a needed KFD-2 trust taxonomy value is missing? | [`KFD-2-usage.md`](KFD-2-usage.md#trust-taxonomy) — open a KFD GitHub issue |
 | What does a specific decision say? | [`../decisions/`](../decisions) (index: [`../registry.json`](../registry.json)) |
 | What machine metadata should Buildchain or another consumer import for KFD standard identity and schema IDs? | [`../standards.json`](../standards.json) |
 | What schema validates the standards metadata surface? | [`../schemas/kfd-standards.schema.json`](../schemas/kfd-standards.schema.json) |
-| What schema should release systems use for KFD-2 release claims and trust passports? | [`kfd-2-release-trust.md`](kfd-2-release-trust.md) |
+| What schema should release systems use for KFD-2 release claims and trust passports? | [`KFD-2-usage.md`](KFD-2-usage.md) — release passports are a KFD-2 projection |
 | How do I cite a decision? | [`../README.md`](../README.md) — cite by number, e.g. `KFD-1` |
 | How do decisions change over time? | [`../CONTRIBUTING.md`](../CONTRIBUTING.md) — append-only; explicit supersession mints a new number |
-| How is this package versioned and released? | [KFD-1](../decisions/kfd-1.md) applied to itself; Buildchain governs releases |
+| How is this package versioned and released? | [KFD-1](../decisions/KFD-1.md) applied to itself; Buildchain governs releases |
 | What release impact ledger should Buildchain consume for production passports? | [`../release-impact.json`](../release-impact.json) |
 | What release provenance path must alpha promotion use? | [`release-governance.md`](release-governance.md) |
 | How do I verify registry/document agreement? | `node scripts/check.mjs` |

package/kfd.release.json

@@ -4,7 +4,7 @@
   "line": "v1.0",
   "channel": "alpha",
   "npmPackage": "@kungfu-tech/kfd",
-  "npmVersion": "1.0.0-alpha.19",
+  "npmVersion": "1.0.0-alpha.20",
   "source": {
     "repository": "kungfu-systems/kfd",
     "branch": "alpha/v1/v1.0"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kungfu-tech/kfd",
-  "version": "1.0.0-alpha.19",
+  "version": "1.0.0-alpha.20",
   "description": "Kung Fu Decisions (KFD): the kungfu-systems organization-wide decision registry, as a consumable artifact",
   "license": "Apache-2.0",
   "files": [
@@ -35,6 +35,8 @@
     "./scripts/*.mjs": "./scripts/*.mjs",
     "./buildchain/kfd-1/contract-world.witness.json": "./.buildchain/kfd-1/contract-world.witness.json",
     "./buildchain/kfd-2/public-release-trust.claim.json": "./.buildchain/kfd-2/public-release-trust.claim.json",
+    "./buildchain/kfd-2/kfd-foundation.trust-claims.json": "./.buildchain/kfd-2/kfd-foundation.trust-claims.json",
+    "./buildchain/kfd-2/kfd-foundation.trust-assessment.json": "./.buildchain/kfd-2/kfd-foundation.trust-assessment.json",
     "./buildchain/kfd-3/collaboration-interface.json": "./.buildchain/kfd-3/collaboration-interface.json",
     "./buildchain/kfd-3/collaboration-interface.prebuild.json": "./.buildchain/kfd-3/collaboration-interface.prebuild.json",
     "./buildchain/kfd-3/collaboration-interface.artifact.json": "./.buildchain/kfd-3/collaboration-interface.artifact.json",

package/registry.json

@@ -9,7 +9,7 @@
       "title": "Facts must not drift: contract worlds need one fact source",
       "kind": "procedure",
       "status": "active",
-      "path": "decisions/kfd-1.md",
+      "path": "decisions/KFD-1.md",
       "url": "https://kfd.libkungfu.dev/1"
     },
     {
@@ -19,7 +19,7 @@
       "title": "Trust must start from facts: responsibility must be inspectable",
       "kind": "principle",
       "status": "active",
-      "path": "decisions/kfd-2.md",
+      "path": "decisions/KFD-2.md",
       "url": "https://kfd.libkungfu.dev/2"
     },
     {
@@ -29,7 +29,7 @@
       "title": "Cooperation must start from trusted value: compliance must not be coerced",
       "kind": "principle",
       "status": "active",
-      "path": "decisions/kfd-3.md",
+      "path": "decisions/KFD-3.md",
       "url": "https://kfd.libkungfu.dev/3"
     },
     {
@@ -39,7 +39,7 @@
       "title": "Timelines must declare their observer: useful views need a stated perspective",
       "kind": "procedure",
       "status": "active",
-      "path": "decisions/kfd-4.md",
+      "path": "decisions/KFD-4.md",
       "url": "https://kfd.libkungfu.dev/4"
     }
   ]

package/release-impact.json

@@ -8,8 +8,8 @@
   },
   "versionImpact": {
     "final": "minor",
-    "source": "kfd-surface-register",
-    "rationale": "This change additively registers KFD-owned standards metadata, the KFD-2 trust taxonomy, KFD-2 release trust schemas, KFD-3 collaboration-interface schemas, KFD-3 self-verification witnesses, KFD-4 observer-perspective schema, KFD-1 document/interface integrity bindings, and the README-backed KFD site homepage projection while keeping existing registry and decision surfaces compatible."
+    "source": "kfd-site-decision-usage-pages",
+    "rationale": "This change additively exposes decision usage subpage mapping in the KFD site bundle, while preserving existing registry, package, and schemaVersion 1 compatibility."
   },
   "surfaceImpacts": [
     {
@@ -28,13 +28,13 @@
       "id": "kfd-standards-metadata",
       "impact": "minor",
       "class": "additive",
-      "rationale": "standards.json and schemas/ add the KFD-2 trust-taxonomy schema ID, release-claims and release-trust-passport schema IDs, explicit KFD-1/2/3/4 interface versions, KFD-4 observer-perspective schema metadata, KFD document SHA-256 bindings, KFD-owned concept names, KFD-3 fact-source interface metadata, and official-status interface metadata for downstream consumers."
+      "rationale": "standards.json and schemas/ add the KFD-2 trust-taxonomy, trust-claims, trust-assessment, release-claims, and release-trust-passport schema IDs, explicit KFD-1/2/3/4 interface versions, KFD-4 observer-perspective schema metadata, KFD document SHA-256 bindings, KFD-owned concept names, KFD-3 fact-source interface metadata, and official-status interface metadata for downstream consumers."
     },
     {
       "id": "kfd-package-structure",
       "impact": "minor",
       "class": "additive",
-      "rationale": "The npm package now publishes the KFD-2 trust taxonomy, KFD-2 schemas, KFD-2 documentation, KFD-3 self collaboration-interface witnesses, KFD-4 observer-perspective schema, TRADEMARKS.md, public fact-source metadata, agent quickstart/self-proof documentation, Buildchain contract lock metadata, and repository verification scripts through existing schemas/, docs/, standards.json, site/, scripts/, .buildchain/, and subpath exports while preserving existing README.md, decisions/, registry.json, and site/ paths."
+      "rationale": "The npm package now publishes the KFD-2 trust taxonomy, generic trust claims, generic trust assessment, release trust schemas, KFD usage documentation, KFD-3 self collaboration-interface witnesses, KFD-4 observer-perspective schema, TRADEMARKS.md, public fact-source metadata, agent quickstart/self-proof documentation, Buildchain contract lock metadata, and repository verification scripts through existing schemas/, docs/, standards.json, site/, scripts/, .buildchain/, and subpath exports while preserving README.md, decisions/, registry.json, and site/ as stable directories."
     },
     {
       "id": "kfd-buildchain-contract-lock",
@@ -48,18 +48,42 @@
       "class": "additive",
       "rationale": "site/kfd-site.json now exposes generated README-backed homepage.sections and homepage.displayPlan fields, including the adoption-boundary and practice-guidelines homepage sections, and scripts/check.mjs verifies the checked-in bundle matches the README projection so downstream sites can render KFD-owned homepage content without maintaining their own README parser or drifting copy."
     },
+    {
+      "id": "kfd-site-decision-usage-pages",
+      "impact": "minor",
+      "class": "additive",
+      "rationale": "site/kfd-site.json now exposes decisionPages.usagePages, mapping each authoritative KFD decision page to its docs/KFD-N-usage.md child page and stable /N/usage route."
+    },
     {
       "id": "kfd-3-self-collaboration",
       "impact": "minor",
       "class": "release-passport",
       "rationale": "KFD now declares its own participant-facing collaboration interface and ships pre-build plus artifact-side KFD-3 witnesses so Buildchain can audit interface closure in the release passport."
     },
+    {
+      "id": "kfd-3-trusted-value-evidence",
+      "impact": "minor",
+      "class": "additive",
+      "rationale": "KFD-3 collaboration interfaces now declare explicit valueEvidence that binds participant-facing value claims to fact artifacts, evidence artifacts, KFD-2 trust assessments, and residual-risk state."
+    },
     {
       "id": "kfd-2-public-release-trust-claim",
       "impact": "minor",
       "class": "release-passport",
       "rationale": "KFD now ships an explicit machine-bound public KFD-2 release trust claim and passes it into Buildchain release passport generation."
     },
+    {
+      "id": "kfd-2-generic-trust-assessment-core",
+      "impact": "minor",
+      "class": "additive",
+      "rationale": "KFD-2 now publishes generic trust-claims and trust-assessment schemas and dogfoods them through KFD-owned assessment files that evaluate KFD-1 contract-world, KFD-3 collaboration-interface, and KFD-4 observer-perspective claims."
+    },
+    {
+      "id": "kfd-numbered-paths",
+      "impact": "minor",
+      "class": "compatible",
+      "rationale": "Decision documents now use stable numbered paths under decisions/KFD-N.md, while usage documentation uses docs/KFD-N-usage.md to distinguish authoritative decision text from consumer implementation notes."
+    },
     {
       "id": "kfd-release-anchor",
       "impact": "minor",
@@ -71,7 +95,19 @@
       "impact": "patch",
       "class": "compatible",
       "rationale": "The KFD to site-libkungfu-dev propagation graph now targets the downstream site's actual main branch and documents the exact KFD package surfaces consumed by kfd.libkungfu.dev, without changing the release propagation graph contract."
+    },
+    {
+      "id": "kfd-1-compatibility-impact-core",
+      "impact": "minor",
+      "class": "additive",
+      "rationale": "KFD-1 now defines breaking, additive, none, and unclassifiable as the generic compatibility-impact core, with release versioning as one projection rather than the only interpretation."
+    },
+    {
+      "id": "kfd-1-surface-register",
+      "impact": "minor",
+      "class": "additive",
+      "rationale": "standards.json now publishes the KFD package surface register as the KFD-1 fact source, and the KFD-1 witness projects each registered surface class and impact projection from that fact source."
     }
   ],
-  "summary": "KFD v1.0 production promotion is minor-impact because it additively exposes KFD-2 trust taxonomy and release trust metadata, KFD-1/2/3/4 interface version metadata, KFD-3 self-verification witnesses, KFD-4 observer-perspective schema, Buildchain contract lock metadata, document integrity bindings, a README-backed homepage bundle/display plan, and a corrected site release-propagation target for Buildchain and other consumers; existing registry, decision text, site bundle, and propagation graph contracts remain compatible."
+  "summary": "KFD v1.0 production promotion is minor-impact because it additively exposes decision usage subpage mapping in the site bundle, preserves existing package and schemaVersion 1 compatibility, and separates authoritative decision paths from numbered usage documentation."
 }