
KIP
io.github.ldclabsPublished by GitHub account ldclabsv1.0.1Updated Oct 24, 2026
Knowledge Graphs to enable memory persistence, knowledge evolution, explainable interaction.
Overview
KIP is a local MCP server that connects an assistant to a KIP cognitive-memory backend for persistent, provenance-aware agent memory.
- What you can do
- The package exposes the KIP protocol's memory interface to an assistant, so it can store and retrieve propositions, assertions, evidence and provenance rather than plain chat history. The README describes a memory interface with agent intents, scoped and attention recall, belief projection computed at read time, and search patterns that combine retrieval with belief. It also covers proactivity mechanisms such as watches, action gates, dependent listing and payload purge, plus a skill lifecycle. The manifest lists no tools, so the exact tool surface is not documented here.
- When to use it
- Consider it when an assistant needs durable memory that separates what was said from what is currently accepted, keeps history instead of rewriting it, and carries evidence and provenance. It suits self-hosted agent memory setups where a KIP-compatible backend already exists. It is not needed for simple session context or one-off tasks.
- Requirements
- Runs locally as a stdio process, desktop only, installed from the npm package @ldclabs/kip-mcp-server. Requires the environment variable KIP_BACKEND_URL pointing at an HTTP KIP backend endpoint, and the secret KIP_API_KEY. The backend service itself must be running and reachable; the repository states it does not contain a production engine or Brain.
Installation
In SourceWeft
- Open KIP in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
KIP 2.0 — Cognitive State Protocol for Agent Memory
Status
Default development version: KIP 2.0 — normative draft. The repository root contains the current protocol and tooling. KIP v1.0-RC11 is frozen for historical reference and migration; changing the default does not upgrade existing deployments or declare the 2.0 protocol stable.
- The scope is frozen. A new contract enters the draft only together with engine evidence; corrections, simplifications and new evidence do not need that gate (Specification Status).
- Names are stable; revisions are digests. There is one memory package,
kip://profiles/[email protected], one general domain package,kip://domains/[email protected], one standard projection policy,kip:memory-default, one standard strength policy,kip:strength-half-life-30d, and schema IDsurn:kip:2.0:schema:*. A draft revision is identified by its content digest; earlier draft packages are not retained. - Both reference engines pass the whole engine suite — 431 cases in 26 fixtures, none pending. The suite manifest records the verified engine revision.
- No learning result is claimed. Engine runs, bounded models and structural tests are separate evidence from measured Brain behavior, which stays
not_rununtil a Brain evaluation measures it.
What the latest revision changed, and how it was validated, is in the revision record.
Start here
- Agent integration: Memory Interface and the Agent memory card.
- Protocol implementation: Specification, syntax reference, and conformance checks.
- Running a Brain: Anda Brain, a memory service that serves the Memory Interface; see Implementations.
- Developer tools: TypeScript language toolkit (
@ldclabs/kip-lang) and VS Code extension, both targeting KIP 2.0. - Existing v1 users: frozen archive, deployment migration, and repository path changes.
The archived MCP server and Skill implement v1 interfaces; native v2 integration starts with the current Interface and wire contracts above.
An interactive version — pan, zoom, relationship tracing, five guided views — is a self-contained file: download it and open it in a browser.
The one idea
A memory that cannot separate what was said from what is true will eventually lie to its owner with total confidence. KIP 2.0 refuses to collapse three questions:
So a stored Proposition is truth-neutral. An Assertion carries one actor's stance toward it, with mode, confidence, validity and evidence. Belief is not a stored field but an Epistemic Projection computed at read time over the eligible assertions:
Change never rewrites the past. Three kinds of change keep three different histories:
- The world changed. One new Assertion from the time of the change. Temporal succession closes the actor's older value at that point, so a formerly true claim is ended rather than declared wrong, and historical queries still answer with it. Two inferences never succeed one another.
- A claim was wrong. A new Assertion supersedes the old one, which stays on record.
- The Brain misrecorded it. Recording repair invalidates the wrong extraction; the source bytes and everyone's stance stay as they were.
Time is stated as honestly as it is known: asserted_at is when a claim was made, not when it was recorded; a claim with no stated start began no later than that; and a coarse date is a time bound, not an invented instant. A preference is an ordinary claim that changes within its kind — there is no Preference type. Where claims of one slot still conflict, the standard memory policy kip:memory-default resolves them the same way on every engine: context specificity first, then first-person testimony, then recency.
Evidence, provenance and schema get the same treatment: Evidence and Activity are first-class elements rather than metadata bags, and schema lives in versioned, digest-pinned packages. A Brain that meets a relation the Profile lacks drafts it into the Space's draft vocabulary with DEFINE, which only adds; promoting a draft onto an installed symbol is a Schema migration that only a Principal holding manage_schema performs. Retrieval composes with belief in one query through the Search Pattern: search finds candidates, and BELIEF decides what is accepted.
The proactivity layer
A memory that only answers when asked is half a memory. The other half is what the Brain does when nobody is talking to it — and it must not be a cron job. KIP 2.0 gives that half four mechanisms, none of which decides policy on the Brain's behalf:
Supporting state lives in the Cognitive Memory Profile: WorkingState is the consolidated resume digest stamped with its basis_seq, so a Brain wakes from compiled state plus a delta rather than re-reading scrollback; computed dependency validity makes a revised root visible at the next read; and MnemonicState.utility holds the admission bet — how useful this memory is expected to be — kept deliberately separate from salience, from memory_strength, and from epistemic confidence. Strength itself is computed at read time from a base, an anchor and a pinned decay policy; nothing sweeps it, and reading never reinforces it.
The consequence channel
Everything above makes the system watch the world better. The consequence channel is how the world watches back.
Outcome Evidence records what actually happened after a decision, action, or trialed procedure — written by instrumentation (telemetry, verifiers, test harnesses, human review), never by the actor whose action it grades. An actor's own account is agent_statement, citable as context only; the separation is a conformance invariant, enforced as auditability — engine origin always records who wrote what, and Governance can restrict who may write outcomes — because an open protocol can make self-grading visible even where it cannot make it impossible.
Each outcome carries a task family that selects candidate consequences. Sharing the family establishes neither attribution nor baseline membership: under the optional Validated Learning companion, TrialRecord explicitly freezes comparable baseline attempts and outcomes. Treatment observations link through the instrument's outcome_observation Activity to an attempt and the action_gate decision that applied the exact Skill revision. Its DecisionRecord distinguishes retrieval from actual use, and grading counts independent attempts assigned before execution. A SkillRevision must name its task family before trial; a pattern that nothing could prove wrong is not procedural memory. On the channel sits the Skill lifecycle:
Lifecycle changes commit with a validated immutable EvaluationRecord on a lifecycle_verdict Activity and a guarded update (Validated Learning §7). Auditors replay exact inputs against the immutable TrialRecord; a Skill's current_trial only selects it, and its GradingState is a computed view. Without the companion, Skills stay unproven candidates — useful, recallable, never promoted. Only trialed → adopted promotes through a comparative verdict, and revocation is never harder than adoption. Same-state monitoring may retain standing under authorized policy without claiming new improvement; policy withdrawal may have zero outcomes. Imported Skills enter proposed without local grades and remain recallable as unproven candidates. Revoked Skills must enter a new trial before adoption can recur.
Protocol provides signals; the Brain owns policy
KIP does not define an admission threshold, an interruption policy, a salience algorithm, a consolidation schedule, or a skill compiler. It defines where those decisions put their inputs and their receipts. A protocol that hardcoded one utility function would stop being a protocol — and every deployment would fork it.
The policy layer is a separate, replaceable component:
- Brain 2.0 — the reference design: Formation (what deserves to outlive this turn), Recall (what from the past should change what I do next), and Maintenance (the sleep-time metabolism that consolidates, compiles skills, reviews contradictions, and metabolizes memory strength).
$self/$system— the single-agent variant, a thin delta layered on the Brain policies above: a waking mind that experiences, and a sleeping mind that integrates.- Experience Learning Architecture — the loop the Brain implements, and how to evaluate whether it actually learned anything rather than merely stored more.
The seam matters in both directions. Because policy is out of the protocol, two Brains with different admission utilities can share one Cognitive Nexus; and because the signals are in the protocol, either Brain's decisions remain auditable by the other.
Memory should be portable
If memory is what makes an agent valuable, the natural move is to make it impossible to leave with. KIP takes the opposite position: cognition exports as a signed, inspectable Cognitive Capsule, and import is a destination-governed transaction — a capsule's signature proves origin and integrity, never truth, trust, or authority. Imported skills stay non-executable until the destination elevates them; a source's $self never becomes the destination's.
Implementations
This repository defines the protocol and its tooling; it does not contain a production engine or Brain. Each implementation's own repository is the authority on what it supports — this table claims nothing beyond the evidence it links.
Documents
Chinese *_CN.md mirrors track the English sources. The English sources are normative; a mirror is not an alternative semantic contract.
Project terminology lives in CONTEXT.md; essays remain in post/.
Repository layout
The usual checks, from the repository root:
AGENTS.md records the contribution rules, and conformance/README.md explains how to run the suites against an engine or a Brain.
Governing principle
KIP 2.0 is a protocol for durable cognition: new information may change what a Brain does next without requiring the Brain to falsify what happened before.
License
Copyright © 2026 LDC Labs. Licensed under the MIT License.
Source: README.md at commit a834eff
Tools
0Version history
1- v1.0.1LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts