Kungfu UNGFU™Developer Platform

Back to KFD-7usage / KFD-7

KFD-7 usage

Real-world action must keep state, occurrence, and action coordinates distinct

Usage metadata

Decision
KFD-7
Stable URL
https://kfd.libkungfu.dev/7/usage
Source path
docs/KFD-7-usage.md
Relationship
usage-child-of-decision

KFD-7 Implementation Notes

Authoritative decision · Formal reference · Documentation map

KFD-7 defines an active Fact-Episode Ontology and a cross-domain action model. Facts preserve admitted state, Episodes preserve replayable causal occurrence, and Action Responsibility Geometry keeps perspective, direction, and authority independently addressable. The authoritative text is decisions/KFD-7.md; its registry status is active.

Package surface

  • decisions/KFD-7.md: the authoritative active decision.
  • docs/KFD-7-activation.md: the retained cross-product qualification cut, review boundary, and non-claims.
  • evidence/kfd-7/activation-record.json: the machine activation verdict and commit-addressed product witnesses.
  • docs/KFD-7-formal.md: the non-normative Fact/Episode and action responsibility geometry reference.
  • drafts/action-state-separation.md: preserved source-candidate lineage.
  • decisions/KFD-8.md: numbered draft Atlas responsibility, with drafts/atlas-action-perspective.md retained as source lineage.
  • decisions/KFD-9.md: numbered draft Pursuit responsibility, with drafts/pursuit-intent-continuity.md retained as source lineage.
  • decisions/KFD-10.md: numbered draft Warrant responsibility, with drafts/warrant-bounded-authority.md retained as source lineage.
  • standards.json#/standards/kfd-7: identity, status, formal reference, concepts, and digests.
  • schemas/kfd-7/domain-profile.schema.json: version 1 Domain Profile Declaration against the Action Responsibility Geometry.
  • verifier/fixtures/kfd-7/: conforming draft and fail-visible negative declarations.
  • scripts/check.mjs: registry, document, metadata, route, and evidence closure.

The schema fixes the Domain Profile declaration and activation boundary. It does not choose a product store, API, CLI, GUI, Git coordinate, database key, or universal lifecycle vocabulary. Product dogfood still decides whether any concrete Domain Profile deserves stable activation.

Fact-Episode Ontology, Action Responsibility Geometry, and Domain Profiles

The Fact-Episode Ontology distinguishes admitted state from realized causal occurrence. Action Responsibility Geometry is the cross-domain responsibility model over that ontology: Atlas, Pursuit, and Warrant remain independently addressable under cross-component invariants and a conservative session projection. “Cross-domain responsibility model” is its explanatory subtitle, not a second formal term. Atlas, Pursuit, and Warrant are reference action coordinates; Fact and Episode are ontology bindings. None is a Profile.

The core terms use one canonical 2 + 3 reading:

Structure Term Canonical explanatory subtitle
Fact-Episode Ontology Fact Admitted state at a declared evidence boundary
Fact-Episode Ontology Episode Replayable causal record between Fact cuts
Action Responsibility Geometry Atlas Declared perspective over admitted facts
Action Responsibility Geometry Pursuit Continuing direction and progress relation
Action Responsibility Geometry Warrant Bounded authority for admissible transitions

These subtitles explain the canonical terms; they do not create aliases. A Fact is not absolute truth. A Fact Cut is the independently addressable formal carrier of admitted Fact state, not a third ontology binding. An Episode is not proof of success, progress, completion, or authorization. Atlas is not complete reality, Pursuit is not authority, and Warrant is not occurrence.

A Domain Profile declares its product and implementation coordinate, qualification state, two ontology bindings, three action-coordinate mappings, domain field schemas and lifecycle terms, supported transitions, prohibited inferences, evidence obligations, non-claims, extensions, and activation verdict. The complete draft example is verifier/fixtures/kfd-7/valid-domain-profile.json.

Products may map several bindings and responsibilities to one physical record, type, API, service, or familiar session surface. They still declare all five so an independent reader can see which default, projection, source authority, cut, and version carries each decision. This requirement preserves semantic distinguishability and traceability without requiring five user-facing or physical objects.

The canonical terms are:

Use Term
Contract-world state and occurrence Fact-Episode Ontology
Cross-domain model Action Responsibility Geometry
Adopter specialization Domain Profile
Adopter machine artifact Domain Profile Declaration

The declaration expresses the semantic split directly:

ontologyBindings[]    fact, episode
actionCoordinates[]   atlas, pursuit, warrant

There is no combined role array or alternate pre-stable interface.

Each supported transition declares its subject component, operation, Domain Profile state terms, preconditions, effect, receipt, evidence, denial reasons, and residual risk. Unknown mappings and transitions fail closed. Domain Profile state strings do not become universal KFD enums merely because one adopter uses them.

The evidence statuses are planned, passed, failed, and not-applicable. passed binds retained artifacts; not-applicable requires a bounded reason. Activation requires a qualified Domain Profile, no planned or failed obligations, an exact evidence cut, independent review, and retained product witnesses.

Adoption profile

An adopter should expose:

  1. the Fact cut and declared perspective used for judgment;
  2. the continuing direction or intended consequence;
  3. the applicable authority boundary and derivation;
  4. the causal record of what actually happened;
  5. explicit admission of successor facts;
  6. distinctions among occurrence, progress, success, completion, and settlement;
  7. degraded, defaulted, expired, revoked, or missing responsibility.

The concrete store, API, CLI, GUI, and vocabulary remain product-owned through the Domain Profile. Implementations may use Atlas, Pursuit, Warrant, and Episode directly or map domain-native objects to the same responsibilities.

Progressive disclosure

KFD-7 does not require every user to fill out four forms before ordinary work. For a simple task with one goal, one adequate context, one stable permission grant, one execution, and little state change, the expected interface is the familiar session:

goal              <- Pursuit
context           <- Atlas
tool permissions  <- Warrant
run or transcript <- Episode
input and result  <- Fact cuts

The product should construct and retain the underlying responsibilities without requiring the participant to manage them separately. It may infer low-risk defaults or collapse interface steps when:

  • the default derivation remains inspectable;
  • consequence and authority boundaries are bounded;
  • escalation reveals the independent roles;
  • later audit can recover which role supplied each decision;
  • simplification does not synthesize permission, occurrence, or completion.

The interface expands only at a complexity breakpoint: several goals, perspective or freshness changes, delegated or revoked authority, several Episodes, or material Fact branching. This preserves the low-cost session experience while making complex work representable without hidden state.

An adopter should test both directions: simple work round-trips through the action model without semantic loss or object ceremony, and complex work reveals the component whose independence has become decision-relevant.

Qualification by theorem reuse

KFD-7 publishes one conditional theorem for all adopters:

Project(Expand(session)) equivalent_D session

The equivalence is fixed to five observations: direction, perspective boundary, effective authority, causal process, and admitted result. An adopter does not need to rediscover or restate that generic claim. Its qualification record instead:

  1. cites the standard theorem and context-insufficiency corollary;
  2. identifies its concrete Expand, Project, and SessionCompressible implementations;
  3. supplies refinement evidence for all five observations;
  4. supplies negative fixtures at declared complexity breakpoints;
  5. supplies same-payload fixtures whose valid action sets differ because Pursuit, Warrant, or Atlas cut and freshness differ.

This turns repeated open-ended model review into a bounded refinement check. It does not remove product testing: runtime correctness, interface usability, cross-domain transfer, and residual risk remain evidence at the adopting Domain Profile’s exact qualification cut.

Independent verification

The native and WebAssembly verifier projections package the same schema:

npx @kungfu-tech/kfd verify kfd-record \
  verifier/fixtures/kfd-7/valid-domain-profile.json

The verifier rejects missing ontology bindings or action-coordinate mappings, missing standard theorem references, unknown closed-vocabulary values, incomplete transitions, missing round-trip/context evidence categories, and premature activation. It remains offline, non-qualifying, and non-self-certified. It checks semantic mapping closure and retained evidence references; it does not count physical records, classes, tables, APIs, processes, or interface components. Passing proves only record structure. Counterfactual distinguishability, independent invalidation, runtime behavior, and qualification evidence remain product and release responsibilities.

Activation evidence boundary

The package proves that KFD-7 is numbered, active, routed, digest-bound, formally described, machine-declarable, and backed by two independently reviewed Domain Profiles at exact availability cuts. The activation record does not prove universal minimality, require one physical product shape, or qualify a future adopter’s implementation.