Knowledge and memory

Two boundaries

Knowledge and memory are two independent authority boundaries, not two names for one system.

Knowledge is formal cognition that has been synthesised within an explicit scope, is reusable, and carries its sources. People maintain and review it. It enters the retrieval data plane, and tasks query it during execution under live authorisation.

Memory is the ongoing mechanism that captures, consolidates, recalls and forgets cognition. It is subject-centred, uses a separate database and account, and does not enter the knowledge retrieval data plane.

They are separate for governability: knowledge needs authoritative sources and review, while memory needs frequent reads and writes and personalised recall. Putting both in one store means either knowledge gets polluted by noise, or memory gets slowed down by governance.

Knowledge spaces

Knowledge is divided into two spaces.

Repository knowledge describes what a repository can currently prove through its code, tests and configuration. It evolves along with the repository's own versions.

Project knowledge synthesises cross-repository cognition, engineering experience, constraints and decisions from many tasks and repositories. It is where compounding across tasks happens.

A decision is special knowledge that a person confirms and that changes project direction, constraints or trade-offs. Project knowledge is the sole authority for the body of a decision, and preserves supersede and revoke relationships.

Live recall

Knowledge has to have both a governance plane and an execution plane. Storage and a UI with no execution-time consumption interface do not add up to a complete knowledge product.

When a task is created, the control plane issues a minimal knowledge access delegation based on the task subject, the organisation and the workspace, and forcibly injects the system knowledge recall skill into every node. The flow and node library neither displays nor allows removal of that system skill.

During execution the agent queries the latest effective content live through a read-only interface. Every call re-checks subject, organisation, workspace, scope and authorisation, and stores retrieval evidence. After a revocation, the next call is refused immediately.

A task binding does not create a continuing read right. An agent cannot widen the bound scope, and no write access, index management or raw machine credential is exposed. When authorisation has been revoked, the scope no longer permits it, the token has expired, or the organisation does not match, the operation must fail closed.

Documents and versions

A knowledge space is a logical namespace responsible for structure, maintainers and the access boundary. What actually participates in parsing, indexing, retrieval and taking effect is the document.

Each document has at most one editable draft, and saving uses a monotonic revision for concurrency control, preventing silent overwrites. Publishing creates an immutable document version from the current draft, and switches that document's current searchable version once parsing and indexing succeed.

Restoring a historical version only copies the historical body into a new draft; it does not overwrite history and does not publish automatically. Shared parties can read only published bodies and historical versions, and cannot see unpublished drafts.

A knowledge space does not produce a whole-space release, and tasks do not freeze a knowledge space or a document version. Every read selects, in real time, the effective version of each document the reader is entitled to at that moment. This is deliberate: knowledge has to keep updating, while a task's reproducibility is guaranteed by the other parts of its execution specification.

How personal memory is layered

The platform stores personal memory with the user as its subject, covering preferences, experience, identity, goals and agent configuration. It is not copied automatically from complete conversations.

Memory has three layers:

Working memory is confined to one conversation or task, carries an expiry, is traceable to its source, and holds episodic summaries, observations, decisions or open items.

Semantic memory is experience or factual cognition the user can reuse across conversations.

Resident memory is the user identity, goals, preferences, behavioural rules and agent configuration that are resident by default within the context budget.

Every recall preserves the scope, the budget, the revisions chosen, the fusion score and the reason for selection. Conversations and tasks continue to consume only immutable memory snapshots.

How a task consumes memory

When a task is created it freezes a bounded snapshot from the current user, the task text and the default agent configuration. An in-flight task does not drift with personal configuration changes; only a rebuild resolves them again.

The runner writes the frozen configuration, goals and entries into a permission-restricted read-only semantic context, and states explicitly that it cannot substitute for task instructions, project knowledge, repository evidence or authorised tools. Tasks and nodes consume only the preflight snapshot and do not read live memory.

An agent cannot write long-term memory directly. Only a completed task can submit memory evidence, and what it submits is structured content; the subject, task, execution generation, status and revision are bound by the control plane. The sandbox has no memory database credentials and cannot call the memory write interface directly.

The task's terminal-state record and its memory contribution are committed in the same transaction. Delivery uses an idempotency identifier, failures use leases, exponential backoff and a dead-letter path, and a completed task is never rolled back.

What never enters long-term memory

Complete prompts, replies, tool output, secrets, personal information and un-redacted external data must not enter knowledge automatically.

When no retrieval data plane is configured the contract is unchanged and the platform falls back to relational database retrieval; when one is configured but unavailable, conversation degrades to relational retrieval with the reason marked, and task preflight fails closed. A frozen snapshot does not depend on an online index and can still be replayed deterministically.

That is an important availability guarantee: a retrieval data plane outage does not make already-created tasks unexecutable.