Jern Cloud docs

Repository knowledge.

What the people who run a repository hold to be true about it, kept as claims with their evidence and the paths they govern. Held claims ride on every task, the agent recalls more by what it is about to touch, and only a person holds one.

What a claim is

A claim is one thing the people who run a repository hold to be true about it. It has a kind: an invariant that must stay true, an approach that was rejected and why, a decision with the alternative it turned down, a preference of the people, or a fact the agent lacked. It has a statement in plain words, a scope saying where it applies, anchors naming the paths it governs, and evidence: a quote, a pull request, or a session, with the date it was formed. And it has a status. A suggested claim is shown and never sent to a task. A held claim rides on every task. A retired claim stays on the page with its evidence and rides on nothing.

A claim is context, not a rule. The agent's own model judges whether a claim applies to the change in front of it and says so in its summary when it departs from one. What the runner enforces is the baseline, and a claim never changes that.

Turning it on

A workspace policy profile has a switch, Use repository knowledge. On, the baseline the profile writes grants two tools on the run-scoped jern MCP server, mcp__jern__recall_claims and mcp__jern__record_claim. The runner reads that grant from the baseline of the attempt: with it, the held claims ride on the task and the agent may recall and suggest; without it, nothing is read. A repository with its own .jern/baseline.json grants the same two tools under allow. The grant moves the policy digest on the receipt, like any other.

The rules

One repository, never across. Claims are keyed by the repository. A session on another repository never sees them.
In the open. Claims are stored as text and shown on the repository page with their evidence. They are not encrypted, since nothing in them is the agent's; they are what people said. Anyone who can start sessions on the repository can edit them.
Held by people only. An attempt's suggestion and a revert both create a claim as suggested. Nothing suggested reaches a task until a person holds it. A person may also retire a held claim, which keeps it and its evidence on the page and off the task.
Bounded. A repository holds at most 500 claims. A statement is at most 2,000 characters, a scope 500, a quote 600, and a claim has at most 32 anchors. At most 12 held claims ride on a task, in at most 4,000 characters, and a recall returns at most three.
Never a gate. No claim blocks an edit, a command, or a publication. The receipt does not list claims either: the useful moment for a claim is before the change, not after it.
On the record. Every claim created, held, edited, retired, or deleted is an audit event. The attempt card counts the recalls the agent made.

How it flows

Before the agent runs, when the baseline grants the recall tool, the runner asks Jern Cloud for the held claims under its lease and appends them to the task after the request, as a short block naming each claim's kind and date. The request itself is unchanged, since the pull request title and the commit subject come from it.
During the attempt, the agent may call recall_claims with the words of what it is about to do and the paths it will touch. Jern Cloud ranks the held claims by a text match on the statement, scope, and anchors, adds the share of each claim's anchors those paths touch, and returns the top three with their evidence and dates. Each recall is counted on the attempt.
When the agent witnesses a claim, a correction it received, a fact it had to discover, an approach that turned out wrong here, it may call record_claim. The claim is stored as suggested, with the attempt as its source and the agent's own quote as its evidence.
When a session's merged pull request is reverted, Jern Cloud suggests a claim of kind rejected by itself: the reverted change is named, the reverting pull request is its evidence, and the files the session changed are its anchors.
On the repository page, the Knowledge section lists claims by status. A person holds a suggestion, edits a claim's words and paths, retires or deletes one, or adds a claim outright, which is held as soon as it is saved.

What a claim looks like

kind:       invariant
status:     held, since 2026-09-07
statement:  A session must never fail on a token or trace-size cap after
            minutes of work. On exhaustion, publish what exists.
scope:      the cap enforcement path and the trace writer
anchors:    runner/run.sh, src/Jern.Cloud.Api/Store/TraceStore.fs
evidence:   "What would be the point of having 45 minutes session if we are
            hitting the limit after only a few minutes"  (session, 2026-09-07)

Why claims and not more rules

The claims worth holding are the ones an agent gets wrong twice: the rounding a codebase never does, the dependency that was tried and pulled, the ordering a reader expects. Mining one developer's own agent transcripts found dozens of such corrections, several restated after the agent broke them a second time. A check that tried to turn them into a gate at diff time put the right claim in the top three for every change it was tested on and still refused too much on the rest. So a claim is what the model reads before it works, with the evidence a reviewer can weigh, and never a rule the runner enforces.

Knowledge, memory, conventions, and skills

Four things tell the agent about a repository. CONVENTIONS.md is what you write for every change. Skills are what you write for particular tasks. Memory is what the agent writes for itself. Knowledge is what people hold to be true, with the evidence for it, surfaced for the change that touches the paths it names. Only conventions and skills are code your reviewers see in pull requests; memory and knowledge live on the repository page.

Not yet

Claims scoped to an organization rather than a repository; a claim's own history of edits; a suggestion drawn from a review that requested changes; and a check the agent runs before it publishes, naming the claims a diff touches.