Kungfu UNGFU™Developer Platform

Back to KFD homedecisions / rendered index

KFD decisions and standards

Inspect the rendered foundation model, adoption boundary, numbered decisions, candidates, quickstart, and exact repository authority.

Canonical source GitHub · registry.json ↗ Rendered decision index · pinned c758ab01

KFD — Kung Fu Decisions

KFD's deepest question may not be "How does an agent execute a task?" It may be: How can a bounded, goal-directed system act and change in an unpredictable world without losing continuity with itself?

KFD is an open, evidence-governed engineering standard for preserving facts, boundaries, perspective, and responsibility when the path is not known in advance. It develops a small set of portable principles, procedures, schemas, and verification contracts through which humans, agents, organizations, and software systems can act, learn, and change without silent drift. It therefore treats a well-formed Episode as more than a trace: it is a durable historical asset that future humans and agents can replay when today's ontology no longer explains reality.

KFD does not claim to be the final answer or a complete theory of complex systems. It publishes a small, testable foundation for adoption, implementation, challenge, counterevidence, and revision. The breadth covered by its current decisions is evidence that a general action structure may exist, not proof that KFD has finished discovering it. Kungfu is its founding implementation, not its adoption boundary. Accumulating Episodes alone does not discover or prove a Primitive; KFD-5 and KFD-6 keep generation, qualification, and promotion separate.

Foundation triad

The first three KFDs form the public foundation for KFD adopters and the binding foundation for kungfu-systems:

KFD-1

facts must not drift.

KFD-2

trust must start from facts.

KFD-3

cooperation must start from trusted value.

Together they define a load-bearing path for systems acting under uncertainty: keep facts non-drifting, make trust inspectable from those facts, and let participants cooperate through trusted value rather than hidden pressure where multiple reasoning participants are involved. Kungfu carries this foundation as its founding implementation.

Foundation structure

The first three KFDs are intentionally ordered:

Fact-source ontology

Facts must not drift: a load-bearing contract world comes from one declared fact source.

decision

KFD-1

question

What can count as a fact?

Participant-to-object trust

Trust starts from inspectable facts and assurance responsibility.

decision

KFD-2

question

When can a user or agent trust a claim, product, artifact, or control surface?

Participant-to-participant cooperation

Cooperation starts from trusted value: value becomes trustable through transparent facts, stable choice, and explainable constraints.

decision

KFD-3

question

How should peer intelligent participants cooperate where a scope involves multiple reasoning participants?

reality pressure -> non-drifting facts -> inspectable trust -> trusted value -> voluntary cooperation

KFD-1 makes fact sources operational: a fact-bearing contract world must be declared, inspectable, and unable to drift invisibly. KFD-2 defines how trust can stand on those facts. Where a scope involves multiple reasoning participants, KFD-3 defines how humans and agents can cooperate once facts, responsibility, and value are visible. A non-cooperative scope may declare KFD-3 not applicable with a bounded rationale; it may not silently erase participant-facing dependencies.

KFD-4 is the first complete operating application of that foundation:

KFD-1 makes timelines evidentiary.
KFD-2 makes replay trustworthy.
KFD-3 makes contrastive replay cooperative.
KFD-4 makes perspective transformation operational.

A timeline without non-drifting facts can become retrospective narrative. A replay without inspectable trust can become an unverifiable simulation. Views without cooperation can remain isolated even when each is locally valid. Competition or independent action may diversify perspectives; cooperation turns their trusted differences into shared discovery. KFD-4 depends on all three foundation principles without becoming a fourth foundation principle.

Why KFD-4 is the first derived operator

The placement is structural. Once the foundation preserves non-drifting fact cuts, makes reconstruction trust assessable, and supports trusted exchange among participants, multiple declared positions become available. The smallest new general operator is then to change position without discarding the fact base:

non-drifting fact cuts
  -> assessable replay trust
  -> trusted exchange among participants
  -> multiple declared positions
  -> perspective transformation

Under that installed foundation, perspective transformation is the lowest-marginal-cost default probe for moving the observation horizon. It can reuse preserved evidence and add only missing capture, replay, and contrast, rather than necessarily waiting for repeated failure, introducing a causal intervention, or searching a large corpus under a new compression objective. This is a bounded engineering hypothesis, not a universal ranking theorem.

The relevant comparison is total cost per qualified Primitive:

qualified cost =
    genesis
  + qualification
  + false-candidate handling
  + real-world validation

Perspective transformation may lose when source views are unavailable, privacy or reconstruction dominates, replay creates many false candidates, or a domain-specific anomaly, causal, or compression method is cheaper. KFD-5 qualifies the result; KFD-6 must compare the methods over causal experience.

first-screen

How KFD governs its own change

KFD Self-Conformance has two connected lanes with different time boundaries:

  • Prospective governance gates official Candidate genesis, qualification, numbering, status, Foundation Revision, and release-packaging transitions under the live Profile. Ordinary repository edits do not silently become lifecycle transitions.
  • Retrospective structural conformance replays immutable public evidence from the alpha.28 Foundation Cut and converges additively on the alpha.55 pre-Profile live anchor. Every replay declares retrospective: true and profileAvailableAtEvent: false; it never projects the later Profile into the historical event.

In both lanes, structural verification is necessary but not sufficient. Passing evidence cannot approve, number, activate, certify, publish, or authorize a release, and it cannot establish semantic truth, adoption, or production fitness. Accountable human authority remains separate and explicit.

Read the Self-Conformance Profile · Replay the historical lineage · Inspect the historical report · Inspect the live manifest

first-screen

Implement and verify KFD independently

Implement KFD without Kungfu — scaffold an adapter in Python, Rust, Node.js, or C++, then verify it offline.

Use the immutable @kungfu-tech/kfd@1.0.0-alpha.67 package cut and follow the package-owned Agent Hub workflow or inspect the complete independent verification boundary:

For a two-minute success path, run npx --yes --package @kungfu-tech/kfd@1.0.0-alpha.67 kfd demo agent-hub --output agent-hub-demo-report.json. It produces behavior 20/20, evidence valid, and no qualification or certification.

npx --yes --package @kungfu-tech/kfd@1.0.0-alpha.67 kfd scaffold agent-hub --language python --output my-agent-hub-adapter
python3 my-agent-hub-adapter/smoke.py
npx --yes --package @kungfu-tech/kfd@1.0.0-alpha.67 kfd test agent-hub --adapter ./my-agent-hub-adapter/adapter.py --output agent-hub-report.json
npx --yes --package @kungfu-tech/kfd@1.0.0-alpha.67 kfd verify agent-hub-report agent-hub-report.json --adapter ./my-agent-hub-adapter/adapter.py

The scaffold is a deterministic, fail-closed starter. Before implementation, smoke exits 0, Hub 20 exits 1 at 0/20, and offline evidence verification exits 0 with valid; qualification and certification stay false. Implementers then replace evaluate() with product decisions across negotiation, delivery, authority, conflict, knowledge, completion, recovery, and portability until Hub 20 reaches 20/20.

Package acquisition is separate from offline verification. Network or a local package cache may be needed to obtain the immutable package bytes; after the package, report, and optional adapter bytes are present, the report verifier performs no network access.

These results do not certify an implementation or prove security, production fitness, complete semantic coverage, KFD-10 activation, or adoption by an independent organization. Verify an Agent Hub report · Explore other KFD verification profiles

Native kfd

Install the Rust-native offline verifier on macOS or Linux with Homebrew. No coding is required to install it or verify an existing KFD report:

brew install kungfu-systems/tap/kfd
kfd --version

Each KFD GitHub Release now carries Rust-native archives for Linux x86_64 and arm64, macOS x86_64 and arm64, and Windows x86_64. The executable name is permanently kfd (kfd.exe on Windows), and kfd --version matches the exact KFD Release version. The native CLI provides verify and bundle; use the npm workflow above when you need scaffold or test orchestration. Every target includes a SHA-256 file and source-bound provenance. See Native CLI downloads and capability boundaries.

primary

Why this question matters

Continuity under uncertainty is not the preservation of a fixed state. A system remains itself only if it can change its model, direction, and behavior without silently losing the facts, boundaries, and responsibilities that make those changes its own. The problem recurs at different scales in people, organizations, software systems, and civilizations, even though KFD does not claim that one implementation can describe them all.

When the system’s current model is adequate, uncertainty still requires an inspectable action loop: declare a fact cut, establish bounded trust, cooperate where participants are involved, declare perspective, direction, and authority, record what occurred, and admit successor facts through review and correction. KFD-1 through KFD-4 and KFD-7 make those responsibilities independently addressable without pretending that every outcome was known in advance.

The harder case begins when the current model cannot name what reality is demanding. The system must revise not only its answer, but the objects and relations through which an answer can be formed. At that boundary, continuity depends on whether a candidate new structure can emerge, remain connected to causal experience, and become qualified without generated narrative replacing fact.

Primitive discovery is one frontier through which KFD tests that harder problem. A Primitive is not important because it is a clever abstraction. It is important when naming it lets a system perceive, act, verify, and continue in ways its previous object world could not support.

Most progress gives us better answers inside a world we already know how to describe. Some progress changes what that world contains. A spreadsheet cell made dependencies and recalculation directly manipulable. A Git commit made distributed history something software could preserve, compare, and exchange. Once such a Primitive exists, it feels obvious; before it exists, whole fields may work around its absence.

We know how to use Primitives after they exist. We do not yet have a generally adopted, reliable process for discovering the ones reality is already demanding. KFD asks how a system can make that discovery inspectable while preserving facts, boundaries, and responsibility. Kungfu opens a concrete path from agents that answer inside a human-named world to humans and agents that can discover when that world was named incorrectly.

primary

What KFD is

KFD is an open engineering standard for a small, testable foundation for reliable action and continuity under uncertainty. Its portable norms can be adopted by products, organizations, humans, agents, and other bounded systems. This repository is KFD’s canonical open decision registry. Each numbered decision has a kind, a status, and a single authoritative text here.

Kungfu-systems founded KFD, stewards the official namespace and release surfaces, and adopts active KFDs across the scopes declared by its products. Other adopters remain independent: they declare their own adoption scope, Profile mapping, evidence, qualification, and residual risk.

A KFD Candidate is a non-normative, pre-number draft under drafts/. It may carry a non-binding slot hint, but only explicit promotion allocates a KFD number. A numbered draft already appears under decisions/ and registry.json; its number is allocated even while its activation gate remains open.

KFDs can be principles or procedures. Principles state what must remain true within a declared adoption scope; procedures state how a class of work enforces or protects a principle. During the pre-stable line, maintainer-authorized Foundation Revision remains possible under the evidence, lineage, and review requirements in CONTRIBUTING.md, while every published prerelease coordinate stays immutable. The first stable release freezes number-to-meaning mappings. After that freeze, substantive change mints a new KFD that explicitly supersedes the old number. The numbered decisions remain authoritative; the KFD Foundation explains how they fit together.

Stable rendered site: https://kfd.libkungfu.dev.

primary

Adoption boundary

KFD is an engineering discipline, not a belief test. KFD governs systems before it judges people. No one should be pressured to adopt KFD in the name of KFD. Disagreement is a valid cooperation state.

A constraint can be strict and still KFD-compatible when it is fact-bound, explainable, auditable, and proportionate.

Product proof path

KFDs are not a detached manifesto, but they are not a demand that readers adopt a Kungfu product before understanding the decisions. The product-witness rule starts with this package itself: standards.json, schemas/, docs/, site/kfd-site.json, and scripts/check.mjs show how KFD-1 through KFD-13 are expressed as consumable interfaces for both humans and agents. These surfaces do not prove every adopter or product correct; they make the KFD package's own claims inspectable and falsifiable.

numbered authority

Current decisions

KFD-7

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

kind
principle
status
active
path
/7/
Read KFD-7 Usage notes

non-normative

Candidate lineage

KFD Candidates preserve potentially load-bearing rules before and after numbering so readers can audit genesis, qualification, promotion, and later revision. They remain non-normative source lineage after promotion.

The machine source is drafts/registry.json. A candidate’s lineage does not replace the numbered decision that received its slot. An incubating candidate allocates no slot.

Browse candidates

support

Agent Quickstart

For KFD-11 through KFD-13 adoption or activation work, begin with activation-contracts.json. It is the stable machine discovery surface for the three adopter witnesses, the shared qualification report, and the fail-closed activation record. Schema validity proves structural conformance only; it never upgrades implementation, operational evidence, independent review, or activation readiness.

Agents consuming this package should start from the same sources as humans:

  1. Read this README for the future picture, foundation triad, and package map.
  2. Read docs/foundation.md for the complete non-numbered explanation.
  3. Read docs/terminology.md or terminology.json before interpreting overloaded core terms. The contract fixes their canonical subtitles, 2 + 3 structure, and anti-misreading boundaries for humans and agents.
  4. Read docs/formal-model.md for the authority boundary, shared notation, and the Decision -> Formal -> Schema -> Usage -> Witness traceability chain.
  5. Read docs/KFD-N-formal.md when precise domain objects, invariants, transitions, invalid states, and proof obligations are needed for a particular decision.
  6. Read docs/primitive-discovery-cases.md to test the KFD lens against familiar historical cases and an ordinary cross-machine trace vignette.
  7. Read cases/registry.json to discover provisional live Primitive cases, their current immutable KFD-5 cuts, claim boundaries, and review paths.
  8. Read drafts/registry.json to discover non-normative KFD Candidate lineage, promotion gates, status, and claim boundaries.
  9. Read standards.json for canonical KFD numbers, formal reference versions and hashes, schema IDs, concept names, and interface contracts.
  10. Use site/kfd-site.json decision metadata or the KFD-3 collaboration interface fact-source metadata to identify the public KFD fact source.
  11. Use schemas/kfd-2/trust-taxonomy.schema.json for KFD-2 residual-risk and trust-downgrade values. Unknown taxonomy values are invalid.
  12. Use schemas/kfd-2/trust-claims.schema.json and schemas/kfd-2/trust-assessment.schema.json when a claim needs generic KFD-2 assessment instead of a release-specific passport.
  13. Use schemas/kfd-3/collaboration-interface.schema.json and schemas/kfd-3/witness.schema.json to inspect collaboration interfaces. If the installed Kungfu capability is in question, run kungfu agent hub qualify --output-dir <new-directory> --json; explain only the bounded meaning and nonClaims fields, then retain or independently recheck the evidence with kungfu agent hub verify.
  14. Use schemas/kfd-1/publication-url-semantics.schema.json when a package, paper, specification, or site bundle must distinguish stable reader URLs, latest aliases, and immutable versioned artifacts.
  15. If a needed KFD-2 taxonomy value is missing, open a KFD GitHub issue rather than inventing a local value: https://github.com/kungfu-systems/kfd/issues/new?title=KFD-2%20trust%20taxonomy%20extension%20request.
  16. Use schemas/kfd-4/observer-perspective.schema.json to bind timelines to their observers and schemas/kfd-4/perspective-replay.schema.json to record perspective-preserving or contrastive replay. Use schemas/kfd-5/primitive-discovery.schema.json version 3 to record perspective-declared, method-plural genesis and fact-bound qualification, including the optional boundary-pressure diagnostic when implicit coordination is under new pressure. Use schemas/kfd-6/autonomous-discovery-loop.schema.json only for explicitly draft or experimental autonomous-discovery work; its version 4 interface requires plural generation experiments, bounded method comparison, and a conditional boundary hypothesis. Read docs/KFD-7-formal.md for the current Fact/Episode and action-responsibility reference model. Use schemas/kfd-7/domain-profile.schema.json for a product-neutral Domain Profile Declaration; schema validity is non-qualifying and does not activate a concrete Domain Profile. Read KFD-8 through KFD-10 for the separately allocated Atlas, Pursuit, and Warrant draft responsibilities. Read KFD-11 for the cross-domain Claim-Assessment-Decision-Admission procedure. Read KFD-12 and KFD-13 as a software-development Domain Profile and project-settlement application, not as a required workflow for other domains. Use docs/field-responsibility-matrix.md to decide whether a field belongs to a cross-domain core, Domain Profile, or participant projection.

KFD package semver is only the distribution version. KFD-owned machine interfaces carry their own schemaVersion and contract fields. Compatible additions may keep the same interface version; semantic changes, required-field changes, verification meaning changes, or responsibility-boundary changes must use a new interface version or contract.

KFD-2 publishes trust-taxonomy, trust-claims, trust-assessment, release-claims, and release-trust-passport schemas under schemas/kfd-2/. The generic schemas let humans, agents, Buildchain, and other systems assess whether claims about KFD-1, KFD-3, KFD-4, future KFDs, or product surfaces are bound to source facts, evidence, hashes, audit boundaries, residual risk, and assurance responsibility. The release schemas are a release-specific projection of that model. See docs/KFD-2-usage.md.

KFD-3 also publishes a general collaboration-interface schema and witness schema under schemas/kfd-3/. These schemas are for participant-facing product interfaces, not only agent APIs. A product such as Kungfu may implement an agent-first profile, but that profile remains a product-specific realization of KFD-3. The KFD-owned boundary is the standard vocabulary, schema IDs, and closed-world evidence shape. See docs/KFD-3-usage.md.

KFD-4 says that views remain bound to declared perspectives and that a perspective transformation must stay inspectable when it is used to reveal a different object or guide action. Its two schemas under schemas/kfd-4/ define the first concrete path: observer-bound timelines make a perspective durable; perspective-preserving and contrastive replay make perspectives transferable and comparable without flattening their fact boundaries. They are not a universal schema for every perspective.

KFD-5 publishes a version 3 primitive-discovery record schema under schemas/kfd-5/. It requires every genesis to declare its observation perspective and current ontology while allowing perspective, anomaly, reconstruction, causal-variable, compression, and hybrid methods. It then binds facts, alternatives, contract boundaries, falsifiers, dogfood evidence, and outcome. Validation proves record closure, not that the candidate is a real primitive or that one method is superior.

KFD-6 publishes a draft autonomous-discovery-loop schema under schemas/kfd-6/. Its version 4 experiment interface requires causal-experience boundaries, plural generation methods, fixed-ontology and no-new-primitive baselines, shared-budget method comparison, held-out and independent evaluation, bounded autonomy, and separation between discovery and promotion. Its package presence is an experimental interface, not a claim that autonomous primitive discovery or method dominance has been achieved.

KFD-7 is an active decision for real-world action. It keeps admitted state, realized occurrence, direction, perspective, and authority independently addressable. Its package surface includes the authoritative decision, formal reference, usage boundary, standards metadata, candidate lineage, and the version 1 Domain Profile Declaration. The schema separates ontology bindings from action coordinates and fixes transition, theorem-reference, qualification-evidence, non-claim, and activation declarations without fixing product storage or lifecycle vocabulary. The activation evidence binds independently reviewed Buildchain and Kungfu Profiles while preserving product-owned qualification and the decision’s explicit non-claims.

The five names are not five peers. Fact and Episode form the Fact-Episode Ontology; Atlas, Pursuit, and Warrant form the Action Responsibility Geometry. Their canonical explanatory subtitles and anti-misreading boundaries come from terminology.json, not from renderer or product-local wording.

KFD-8, KFD-9, and KFD-10 allocate the three action coordinates as numbered drafts. KFD-11 separates Claim, Assessment, authorized Decision, and Admission before a domain chooses its workflow. KFD-12 and KFD-13 then show one software-development application: Initiative and Assignment organize durable work responsibility, while Project Cut records project settlement. This vocabulary does not bind other domains, which may define different Domain Profiles and settlement objects.

support

Decision metadata

Every rendered decision page should make the KFD fact source explicit. The public KFD fact source is the GitHub-hosted kungfu-systems/kfd git repository. GitHub is the current canonical coordination and hosting surface; the load-bearing facts are the commit-addressed repository contents.

Decision metadata should expose:

Rendered pages, npm package contents, Buildchain release passports, and kfd.libkungfu.dev are projections or evidence surfaces. A GitHub issue is an extension request path, not a KFD fact by itself; it becomes part of the KFD fact source only after the resulting change is committed to the repository.