Kungfu UNGFU™Developer Platform

Back to libkungfu.devarchitecture / complete model

How the continuity stack works

Follow the full path from recorded action and plural-Hub cooperation to runtime qualification, release trust, and public evidence.

01 · Guided synthesis · site-owned

Long-running Agent work needs a continuity stack, not one longer session.

A session is a useful interaction boundary. It is not enough to preserve admitted state, causal experience, continuing responsibility, or an accepted project result across agents, machines, repositories, and days.

  1. First-screen propositionsite-libkungfu-dev
  2. Guided synthesissite-libkungfu-dev
  3. Upstream authoritykungfu-systems/kungfu, @kungfu-tech/kfd, and @kungfu-tech/buildchain
  4. Machine evidenceupstream authorities projected by site-libkungfu-dev

  1. State and worldline

    Fact + Episode

    A Fact Cut preserves admitted state. An Episode preserves the causal worldline that actually occurred between cuts.

    Sourceskungfu-action-runtimekfd-7

  2. Action coordinates

    Pursuit + Atlas + Warrant

    Direction, declared perspective, and bounded authority remain independently addressable before action is treated as responsible.

    Sourceskungfu-action-runtimekfd-7

  3. Work topology

    Initiative + Assignment

    The Agent Work profile organizes continuing change and bounded responsibility without redefining the lower cross-domain coordinates.

    Sourceskungfu-project-cut-loop

  4. Accepted project state

    Settlement → Project Cut

    Evidence crosses the admission boundary only through explicit settlement; the resulting Project Cut states what the project has officially become.

    Sourceskungfu-project-cut-loop

Agent supply chain

The Agent supply chain separates product ownership from portable trust.

Hub vendors keep the commercially valuable product layer. KFD defines portable cooperation boundaries, libkungfu preserves local runtime facts and Episodes, and Buildchain binds shipped claims to exact artifacts.

Each vendor

Hub

UI, models, accounts, billing, cloud, policy, and customer relationships remain with the Hub owner.

Sourceskfd-agent-hub-profilekfd-3

Open protocol

KFD

Independent Hubs can exchange bounded responsibility without adopting one control plane or one mandatory cloud.

Sourceskfd-agent-hub-profile

Local runtime

libkungfu

The reference runtime preserves admitted Facts, causal Episodes, recovery, and inspectable projections below the Hub product.

Sourceskungfu-action-runtime

Claim boundary: The KFD Agent Hub profile is alpha. It defines an interoperability contract; it does not prove external vendor adoption, plural-Hub deployment, stable certification, or an industry standard. Sourceskfd-agent-hub-profile

Agent Supply Chain

Five responsibilities. Independent owners. One inspectable path.

Kungfu is an open Agent Supply Chain protocol stack for discovering how Agent products cooperate, binding claims to exact software artifacts, establishing purpose-bound trust, preserving durable work facts, and carrying that work across independently owned Hubs.

01 · kfd-3

Owner: KFD

Discover how products cooperate through inspectable value, constraints, choices, commands, Exit, and records.

Input: Product-owned value, constraints, choices, commands, Exit, and record declarations

Output: A stable human-and-agent discovery surface for bounded cooperation

Known limit: KFD-3 discovery is inspectable product guidance, not a hidden prompt or forced adoption mechanism.

npm:@kungfu-tech/kfd@1.0.0-alpha.41#README.md

proved-now
02 · buildchain

Owner: Buildchain

Bind product-owned declarations to exact source, build, artifact, checks, and promotion evidence.

Input: KFD-3-discoverable product declarations and an exact source cut

Output: Artifact-bound provenance, checks, and promotion evidence

Known limit: Buildchain does not create product facts or make the receiver's trust decision.

npm:@kungfu-tech/buildchain@2.14.14-alpha.4#dist/site/product-mechanism.json

proved-now
03 · kfd-2

Owner: KFD and receiver

Assess claims for a declared purpose while retaining residual risk and decision ownership.

Input: Exact-artifact evidence, a declared purpose, and receiver policy

Output: A purpose-bound assessment with residual risk and decision ownership

Known limit: KFD-2 is purpose-, cut-, and evidence-bound; it is not a company reputation score or universal trust certificate.

npm:@kungfu-tech/kfd@1.0.0-alpha.41#decisions/KFD-2.md

proved-now
04 · libkungfu

Owner: Kungfu and adopter

Preserve admitted work facts, Episodes, roots, export, and recovery evidence while applications own domain facts.

Input: Receiver-admitted work facts, commands, Episodes, and roots

Output: Ordered durable records, export, recovery, and qualification evidence

Known limit: Applications retain authority over domain facts; libkungfu owns admitted runtime records and ordering within its declared boundary.

git+https://github.com/kungfu-systems/kungfu.git#7eeb5bd1b45492f4da27eaacbe63eddfd6245176:docs/qualification/vendor-agent-hub-embedding.md

proved-now
05 · agent-hub-portability

Owner: KFD profile and each Hub

Carry bounded responsibility objects across independently owned products with receiver-owned admission.

Input: Bounded responsibility objects with rooted evidence and explicit authority

Output: Portable envelopes, conformance results, and receiver-owned admission decisions

Known limit: The public profile enables independent implementations but does not prove a second independent production Hub.

npm:@kungfu-tech/kfd@1.0.0-alpha.41#protocols/agent-hub/manifest.json

enabled-by-protocol

Claim boundary: Kungfu does not claim that a multi-Hub ecosystem already exists. It proves that Agent discovery, software provenance, trust, durable work state, and portability no longer need to be rebuilt or locked inside each Hub.

Inspect machine contract Open the Hub profile

02 · Upstream authority · Kungfu

How libkungfu turns action into an inspectable world

libkungfu does not model everything. It preserves the coordinates needed to act without losing intent, evidence, authority, or continuity.

reference-candidate claim: reference-adopter darwin/arm64
  1. Fact Cut N What is admitted now?

    A rooted view of accepted state, not every observed or proposed claim.

  2. Action Geometry Why, from what view, under whose authority?

    Pursuit preserves intent. Atlas preserves the declared perspective and sources. Warrant bounds permission.

    • Pursuit · why
    • Atlas · what is known
    • Warrant · what is allowed
  3. ActionBinding Which exact inputs authorize this candidate action?

    An immutable intersection receipt over the Fact cut, Pursuit, Atlas, Warrant, action, and resource.

  4. Act What crosses into the real world?

    The runtime may invoke tools or external systems, but success signals do not settle meaning.

  5. Episode What actually happened?

    Causal occurrence, artifacts, receipts, consequences, recovery state, and verification roots.

  6. Inspect + admit Which consequences become Facts?

    Local policy evaluates evidence and admits, rejects, degrades, or conflicts new claims.

  7. Fact Cut N+1 What may safely happen next?

    The successor cut begins the next action loop without rewriting prior occurrence.

next action loop
Append-only journal authority

Typed identity, admission, order, causality, lifecycle, Cuts, refs, and receipts.

Content-addressed bodies

Immutable bytes become usable evidence only when a journal-committed root verifies them.

Rebuildable projections

SQLite, CLI, GUI, JSON, Python, and Node views add access, never hidden authority.

Semantic source: docs/architecture/fact-episode-action-runtime.md docs/concepts/project-cut-product-loop.md docs/concepts/system-overview.md

03 · Upstream authority · KFD

KFD connects plural Hubs without becoming their control plane

Each Hub keeps its product, identity, policy, storage, models, and customer relationship. KFD standardizes only the responsibility exchange boundary.

Participant-owned control plane

Qualified first-party reference adopter

  1. Vendor product · UI, models, accounts
  2. Local policy · identity, authority, admission
  3. libkungfu · Facts, Episodes, recovery
  4. KFD adapter · exchange store and verdict writer
KFD responsibility boundary
  1. Negotiate Select one exact profile version and the safe capability intersection.
  2. Propose Send rooted responsibility, causality, Warrant, disclosure, and payload commitments.
  3. Deliver A replaceable binding returns transport evidence only.
  4. Assess locally The receiver verifies, detects conflicts, applies policy, and writes its own rooted verdict.

Replaceable transport
Local call · IPC · file · HTTP · gRPC · message bus · removable media

Participant-owned control plane

Independent conforming implementation · not yet claimed as adopted

  1. Participant product · UX and workflows
  2. Local policy · identity, authority, admission
  3. Any conforming runtime and evidence store
  4. KFD adapter · exchange store and verdict writer

KFD does not own: No global identity provider, Hub registry, database, transport, clock, or mandatory KFD cloud.

Delivery≠Admission

A receipt proves bytes arrived; the receiver still owns the verdict.

Occurrence≠Completion

An Episode happened; success remains an independently assessed claim.

Authentication≠Authority

Controlling an identity does not prove permission, truth, or fact admission.

Protocol source: protocols/agent-hub/README.md protocols/agent-hub/implementer-guide.md kfd-agent-hub@0.1.0-alpha.1

04 · Guided consequence

The protocol removes shared-infrastructure assumptions.

KFD does not require every participant to share one implementation. It preserves the minimum responsibility semantics needed for independent systems to cooperate without guessing.

Sourceskfd-agent-hub-profilekfd-3
Different Hub internals

Exact profile coordinates and capability intersection

No shared trust root

Receiver-owned admission and non-amplifying Warrants

Retries, delay, and offline work

Content roots, predecessor causality, and idempotency keys

Divergent state

Visible conflict roots and append-only successor exchanges

Private or incomplete context

Typed partial, redacted, reference-only, or withheld disclosure

Vendor and transport exit

Binding-neutral payload digests and export/import

Dogfood · public evidence

The substrate is building itself.

A fixed 30-day snapshot connects public work, exact Cuts, independent review, and production delivery.

Audit the complete evidence chain
3,467 merged public PRs
16 public repositories with merged work
323 retained public Project Cuts

One native authority · three host languages

Start with an Episode

These commands run after building the exact source candidate. Each card links to the single reviewed implementation.

C

Open and close one native Episode

cc quickstart/episode.c -lkungfu -o episode && ./episode ./runtime
Read the exact source
Open the reviewed reference Inspect machine facts

Package availability

Source is ready; registry installation is not claimed

No public registry install is claimed yet. Use the exact reviewed source candidate for evaluation.

@kungfu-tech/core

Node binding over the native libkungfu authority

Status: source-candidate

@kungfu-tech/opencode-kungfu

Replaceable OpenCode reference adapter

Status: source-only-private-package

Data and authority boundary

Record lifecycle evidence, not customer payloads

Retained by the reference adapter

  • Episode open, heartbeat, end, or abort lifecycle
  • Adapter-owned phase labels
  • Native timestamps and aggregate heartbeat counts

Deliberately dropped

  • Prompts and message content
  • Tool arguments, outputs, and errors
  • Provider, model, token, and credential data

Observed evidence · exact candidate

KFD Runtime 100 and restart qualification

35/35Core
65/65 non-normativeExperimental
100paired hooks
2.4 msobserved p95 hook latency

SIGKILL restart recovered one unsealed Episode; export, import, and both fsck checks passed

Read qualification boundary Audit PR #1171

What this does not claim

This is a first-party reference adopter, not external vendor adoption, certification, or OpenCode endorsement.

Release trust

Why the candidate is inspectable

KFD defines principles, Buildchain makes them executable, Core proves them in a complex product, and Kungfu Tech carries future products.
kfd.libkungfu.dev

Kung Fu Decisions

Principles

KFD defines the shared rules: what can count as a fact, when a product claim can be trusted, and how intelligent participants should cooperate.

Open KFD
buildchain.libkungfu.dev

Buildchain surface

First load-bearing layer

Buildchain turns those principles into executable release infrastructure: version decisions, release passports, provenance, rollback, and propagation.

Open Buildchain
core.libkungfu.dev

Kungfu product map

Runtime substrate proof

Core shows how libkungfu turns runtime events into retained, observable evidence while keeping visibility, durability, and authority boundaries explicit.

Open Core

Future products

Kungfu Tech

Future Kungfu products belong on kungfu.tech as the user-facing product home. libkungfu.dev explains the generation mechanism those products should be able to trace back to: declared facts, Buildchain release evidence, and inspectable KFD decisions.

Source boundary

Projection source: The site owns first-screen framing, cross-surface synthesis, reading order, progressive disclosure, navigation, and visual composition. Every technical or release claim must bind to immutable upstream evidence or a pinned package; core specs, KFD semantics, CLI parameters, workflow inputs, release state machines, schemas, and provenance remain upstream-owned.