Memory & Decisions — Conceptual Deep Dive

Purpose and mental model

Memory and decisions give an Agentweaver team a shared operating record. Agents do not only produce code or prose; they also learn project-specific facts, notice reusable patterns, and propose constraints that future agents should respect. The system has to preserve those observations without letting every transient thought become team law.

Think of the design as a shared ledger with a drop-box in front of it:

1. Agents write observations to the inbox when they discover something that may matter beyond the current run.
2. The inbox is reviewable and durable. Pending, merged, and rejected entries remain explainable.
3. Promotion creates canonical decisions. Accepted entries become active decisions in the project ledger.
4. Memory stays lower priority than decisions. Memory helps an agent work; decisions constrain what the whole team is allowed to do.
5. Exports mirror the ledger to files so humans and agents can inspect the current state in .squad/ and .agentweaver/context/.
6. Immutable revisions preserve the audit trail. Updates and restores append snapshots instead of rewriting history.

The key governance idea is separation: agents may propose, but only accepted decisions become authoritative boundaries. Acceptance is provenance-aware: a project owner or a verified Coordinator run controls manual promotion, merge, rejection, and active decision mutation. That keeps team knowledge cumulative while preserving a deliberate write boundary around project policy.

Where this lives:

• apps/Agentweaver.Api/Memory
• apps/Agentweaver.Api/Endpoints/DecisionsEndpoints.cs
• apps/Agentweaver.Api/Endpoints/MemoryEndpoints.cs
• packages/Agentweaver.Squad/Memory

Core concepts

Decision

A decision is an accepted rule, fact, or policy for a project. Active architectural and scope decisions are treated as non-negotiable boundaries when context is compiled for agents. Decisions can also be superseded or archived; supersession preserves why the old rule existed while pointing to the replacement.

Decisions are the highest-priority memory artifact. They answer: "What has the team accepted as true enough to govern future work?"

Decision inbox entry

An inbox entry is a proposed decision, learning, pattern, or update. It is not automatically authoritative. It carries an agent name, project, slug, type, title, content, rationale, status, and an optional link to the decision created when it is merged.

The inbox exists because agents are useful observers but noisy policymakers. A run can deposit a candidate item without directly changing the team's canonical operating rules.

Agent memory

Agent memory is reusable context associated with a named agent. It stores core context, learnings, patterns, and updates with an importance level and optional tags. Approved memory tagged cross-team can be selected for agents other than the original author.

Memory can be active, superseded, or archived. Normal retrieval and prompt selection use active records only. A superseded record points to an acyclic replacement inside the same project.

Memory answers: "What may help this agent or the wider team do better next time?" It should not override accepted decisions.

Provenance and trust

Memory and decisions retain server-resolved provenance:

• sourceKind: human, run, or legacy;
• sourceIdentity: the authenticated user or verified run:{id};
• sourceRunId: the originating run when applicable;
• trustState: pending, approved, or legacy for memory and decisions;
• approvedBy and approvedAt: the approval audit trail.

Agent loopback writes require a short-lived run capability in addition to the internal API key. The API resolves the project and agent from that verified run and rejects a forged agent name.

Memory recorded through the API starts pending. It can inform its named agent, but cross-team selection requires approved. Active architectural and scope decisions also require approved before compilation. Records that predate provenance tracking migrate as legacy and remain visible but fail closed: they are excluded from every prompt until explicitly approved.

Session context

Session context is the current work focus for a project. It records the active session id, focus area, active issues, summary, and serialized state. Starting a new session closes older open sessions so there is one clear "now" for prompt compilation and export.

File mirror

The database is authoritative for API reads, prompt context, and file generation. Files are an interoperability mirror:

• .squad/decisions.md for accepted decisions;
• .squad/decisions/inbox/{slug}.md for pending inbox entries;
• .squad/agents/{agent}/history.md for learning and update memory;
• .squad/identity/now.md for session focus;
• .agentweaver/context/boundaries.md for architectural and scope decisions;
• .agentweaver/context/patterns.md for reusable patterns.

This mirror makes memory inspectable and git-friendly without making markdown parsing the primary consistency mechanism.

All canonical sync paths use one ownership contract. API import/export, scheduled inbox consolidation, and Scribe acquire the same repository lock, then regenerate and optionally commit the mirror. Each exported decision has an exporter-owned record id and content hash, so headings inside a decision body are content rather than record boundaries. A valid older exported record is recognized as a stale mirror and regenerated from the database; a changed marked record reports decision_ledger_conflict and leaves both sources unchanged. Repository-only Markdown is imported as a pending inbox item for Owner or Coordinator review, never as an active approved decision. Inbox and ledger scans reject symbolic links and reparse points before reading them.

Why a shared ledger?

Multi-agent work creates two risks:

• Private knowledge drift: one agent learns a constraint, but the next agent starts from a blank prompt and violates it.
• Policy spam: every agent observation is treated as a durable rule, and the team becomes over-constrained by unreviewed guesses.

The shared-ledger model balances those risks. Agents can always leave evidence. The team can later promote only the evidence that should govern future work. The result is neither purely ephemeral chat history nor an uncontrolled global notebook.

The ledger also creates auditability. A rejected item is still useful because it explains why a proposal did not become policy. A superseded decision is still useful because it explains why an older constraint changed.

Data model as governance state

The memory store is EF Core-backed. SQLite deployments use memory.db alongside the operational database; PostgreSQL deployments include operational entities in the same MemoryDbContext. For governance, the central entities are decisions, decision inbox entries, agent memory, and session context.

The PROJECT ownership edges below are conceptual project scoping, not a claim that every edge is an enforced cross-store foreign key. The model explicitly enforces the optional decision supersession and inbox-to-decision references.

Current memory and decision rows are read projections. Append-only revision tables are the authoritative audit history. Every snapshot carries the stable record id, immutable revision id, predecessor, revision number, actor/source run, reason, timestamp, provenance fingerprint, trust/approval state, lifecycle, and content fields. REST and MCP history responses redact recognized secrets and personal identifiers.

Two database constraints matter most for rebuilds:

• inbox slugs are unique per project;
• session ids are unique per project.

The project-wide slug constraint is intentionally stronger than "unique per agent." It lets a slug behave like a stable project-level handle for a proposed item, while the endpoint layer handles different-agent collisions safely.

The inbox to promotion model

The inbox is a state machine. Its abbreviated pending self-loop below requires the same project, slug, case-insensitive agent name, source kind, and source identity; matching an agent label alone does not authorize an update.

1. A pending entry is created or updated.
2. A project owner, verified Coordinator backstop, or bounded post-run Scribe path decides whether it should be accepted.
3. Promotion creates an active decision, marks the inbox entry merged, records the merge timestamp, and stores the decision id on the inbox entry.
4. Rejection marks the entry rejected; it does not delete it.

The merge/promote endpoints open a database transaction around promotion. The shared promotion helper creates an approved active decision, marks the inbox row merged, and persists its decision link; the caller owns the transaction. A rebuild should preserve that atomic relationship rather than treating the helper alone as a transaction.

There are three promotion paths:

• Manual/API promotion merges one pending inbox entry after authorization as a project owner or verified Coordinator run.
• Post-run Scribe automation auto-merges lower-risk learning, pattern, and update entries only when they match the completed run's agent, creation window, and verified source run id.
• Coordinator finalization backstop promotes run-scoped architectural and scope entries authored by that same verified Coordinator run.

The policy split is deliberate. Routine, verified run-scoped learnings can flow quickly into the ledger. Architectural and scope boundaries are higher impact and remain review-oriented unless the verified Coordinator authored them as part of finalization. An ordinary agent cannot use Scribe to promote a boundary.

Slug de-collision

An inbox slug is the human-readable identity of a proposed item. Slugs are also used as pending inbox filenames during export. Without careful collision handling, two agents can accidentally write different ideas under the same slug and one can overwrite the other.

The current submission rule is:

1. If no entry exists for the project and requested slug, create a pending entry with that slug.
2. If the same agent submits the same slug again and the entry is still pending, update the existing row only when source kind and source identity also match. This makes retries from the same verified author idempotent.
3. If the same agent submits the same slug after it was merged or rejected, return a conflict. Historical entries are not silently reopened.
4. If a different agent, or the same agent with different provenance on a pending entry, submits the same slug, allocate a de-collided slug: original--agent-segment.
5. If that candidate already exists, append a counter: original--agent-segment--2, then --3, and so on. Every numbered candidate loops back through the availability check before insertion.

This prevents a data-loss bug: if the key were only (project, slug) with blind upsert semantics, the second agent to propose "use-postgres" could overwrite the first agent's unrelated proposal. If the key were only (project, agent, slug), both entries could survive in the database but export to the same .squad/decisions/inbox/use-postgres.md path and one file would win. De-collision preserves both proposals all the way through the file mirror.

Slug uniqueness is enforced in two layers. The endpoint first selects a free, de-collided slug before insert by probing candidates until one is unused. The unique (project, slug) database constraint prevents duplicate rows even if two submissions race and pick the same candidate. The endpoint neither retries the failed insert nor maps that uniqueness exception to a dedicated HTTP 409 response. A losing concurrent insert fails; callers must not assume transparent re-allocation.

Memory versus decisions

Memory and decisions are intentionally different:

Aspect	Decisions	Agent memory
Authority	Governs the team	Informs an agent
Review model	Owner/verified-Coordinator promotion, direct creation, supersession	Direct append; owner/verified-Coordinator approval for cross-agent use
Prompt priority	Highest for architectural/scope decisions	Lower than decisions
Scope	Project-wide when active and approved	Agent-scoped unless approved and tagged cross-team
File mirror	.squad/decisions.md, boundaries context	agent histories, shared patterns
Update model	Status changes and supersession	Append new entries; selection is bounded

The difference matters during context compilation. Active, approved architectural and scope decisions are serialized first as boundaries. Non-legacy agent-scoped memory follows; cross-team memory must also be approved. Session context comes last. All selected strings live inside an explicitly untrusted JSON data envelope, so trust controls eligibility without turning stored text into prompt instructions.

The shared context schematic is retained as a reference. The eligibility table below makes the current trust and provenance gates explicit rather than implying that active status or a tag alone is sufficient.

Memory selection is bounded. For run prompts, eligible learning and pattern candidates are filtered and scored by task relevance, then importance and recency; selection stops at the item limit or the first candidate that would exceed the approximate token budget. Core context is part of the fresh-run candidate set; delegated runs omit it and session state while retaining relevant learning/pattern memory. The default limits are 20 items and approximately 4,000 tokens (four characters per token). This budget applies to selected memories, not to decisions or session data.

Compiler input	Eligibility
Project boundaries	Active, approved architectural or scope decisions
Agent core context	Same agent, core_context, non-legacy
Agent learning/pattern	Same agent, high importance, non-legacy
Other-agent learning/pattern	High importance, approved, whole cross-team tag
Session focus	Most recently started open project session

These filters describe prompt selection, not every record returned by the read APIs.

Import and export

Import/export is the bridge between structured database state and human-readable workspace state.

Export

Export materializes database rows into files. It rewrites pending inbox markdown from current pending rows and removes stale pending markdown before writing the new set. That makes the database authoritative after synchronization.

The API's ledger exporter selects active approved decisions, non-legacy memory (with approval additionally required for shared patterns), pending inbox entries, and the latest open session. The DTO-based file writer then produces:

Exported file	Source
.squad/decisions.md	Selected decisions
.squad/decisions/inbox/{slug}.md	Pending proposals
.squad/agents/{agent}/history.md	Selected learning and update memory
.squad/identity/now.md	Current session, when present
.agentweaver/context/boundaries.md	Selected architectural and scope decisions
.agentweaver/context/patterns.md	Approved pattern memory

Decision/inbox mutations and post-run Scribe processing can refresh the mirror. Recording or approving agent memory does not itself perform a synchronous export; those rows wait for an explicit or subsequent Scribe export. Incidental refresh helpers log export failures rather than undoing the main database write. Explicit export surfaces failures instead of reporting a successful sync. None of the output files other than inbox proposals is an import source.

Import

Import scans .squad/decisions/inbox/*.md. Each file needs front matter with agent, slug, type, and title. The body becomes content. A trailing **Rationale:** section is split into rationale. Unparseable files are skipped.

The importer creates missing pending inbox rows by slug and leaves existing slugs alone. It is a union-style import, not a destructive reconciliation. That makes the inbox folder useful as a drop-box for humans or agents without risking deletion of database state.

Import does not bypass review. A file can create a pending proposal, but it cannot directly create an approved decision or repair a legacy record's trust state.

Conflict-free merge model

The ledger is designed to merge by adding facts and changing status, not by rewriting history.

• New memories are appended.
• New inbox entries are appended, with slug de-collision when needed.
• Rejections are status transitions, not deletes.
• Merges retain the source inbox entry and link it to the created decision.
• Supersession links old and new decisions instead of editing the old decision out of history.
• Export regenerates current mirror files from authoritative rows.

This is not a full CRDT, but the operational shape is conflict-minimizing. Independent agents can usually add observations without coordinating. Human-visible conflict points are explicit: the same project slug, the same session id, and the decision to promote or reject.

The important rebuild principle is union first, overwrite only for mirrors. Database state should preserve evidence. Generated files can be rewritten because they are views over that evidence.

Failure modes

Duplicate or colliding slugs

The dangerous case is silent overwrite. De-collision avoids it for different agents and for pending entries whose author provenance differs. Same-agent same-slug updates require pending status and matching source kind/identity, preserving retry safety without reopening history.

Promotion half-success

If promotion creates a decision but does not mark the inbox entry merged, the same proposal can be promoted again. If it marks the inbox entry merged without a decision id, the audit chain breaks. Promotion should therefore be transactional.

Export failure

The database write may succeed while the file mirror is stale. This is acceptable for the current design because the database is authoritative. The cost is that humans inspecting .squad/ may temporarily see old state until a later export succeeds.

Import ambiguity

Malformed inbox files are skipped. This keeps one bad file from blocking all imports, but it can hide authoring mistakes. A rebuild could improve this by returning a warning list while preserving the non-blocking behavior.

Memory bloat

Unbounded memory would produce noisy prompts and high token usage. The compiler must keep a deterministic budget by task relevance, importance, recency, item count, and approximate tokens.

Cross-team over-sharing

The cross-team tag is powerful because it moves memory beyond the original agent. It must be combined with TrustState = approved; a tag on pending or legacy memory is not sufficient. Tags should be normalized with delimiter semantics so searching for team does not accidentally match cross-team, and vice versa.

Legacy data treated as current policy

An upgrade can retain historical rows whose authorship cannot be verified. Marking those rows approved by default would silently elevate unknown text into future prompts. The migration therefore assigns both SourceKind = legacy and TrustState = legacy. The records remain inspectable, but compilation ignores them until an authorized approval records ApprovedBy and ApprovedAt.

Backup gap

The memory ledger lives in memory.db for the default SQLite setup. Any backup plan that captures only the operational database misses decisions, inbox entries, sessions, agent memory, run events, coordinator plans, steering directives, and MCP auth state.

Invariants

A correct implementation should preserve these rules:

• The database is authoritative; exported files are mirrors.
• Project + inbox slug is unique.
• Same agent + same pending slug + matching source kind/identity means idempotent update.
• Different agent, or different provenance on a pending entry, means a new de-collided entry.
• Merged and rejected inbox entries are not reopened by a retry.
• Rejection never deletes the inbox entry.
• Promotion creates an active decision and links the source inbox entry.
• Manual promotion, rejection, approval, and active-decision mutation require a project owner or verified Coordinator run.
• Architectural and scope decisions compile only when active and approved.
• Legacy memory and decisions never compile.
• Agent memory is scoped to the agent unless approved and explicitly tagged cross-team.
• Stored memory, decision, and session strings are serialized as explicitly untrusted JSON data.
• Tags are stored and queried as whole tags, not loose substrings.
• Starting a session closes older open sessions for the same project.
• Export removes stale pending inbox files before writing current pending entries.
• Import creates missing pending inbox rows and does not destructively reconcile the database.
• File writes must stay inside the project workspace.

Design trade-offs

Review buffer over instant policy

The inbox delays authority. That adds one more step before a rule governs the team, but it prevents unreviewed agent output from becoming policy.

Database authority over editable markdown authority

Markdown is easy for humans and agents to inspect. A database is better for transactions, filtering, status transitions, and relationships. Agentweaver chooses the database as source of truth and markdown as a mirror.

Project-wide slugs over per-agent slugs

Project-wide slug identity catches collisions that would otherwise produce the same exported filename. The trade-off is that the endpoint needs de-collision logic for independent agents using the same natural slug.

Append/union over destructive cleanup

Keeping rejected and superseded records increases storage and history length. The benefit is that governance remains explainable. The system can answer not only "what is the rule?" but also "what proposal did we reject or replace?"

Best-effort export over all-or-nothing writes

Failing a database write because a mirror file could not be regenerated would make memory capture fragile. Best-effort export favors durable capture, with the known trade-off that files can lag.

Rebuild blueprint

To rebuild memory and decision governance from these concepts, implement the system in this order:

1. Define entities for decisions, decision inbox entries, agent memory, and session context.
2. Add project/status/agent indexes and unique constraints for project+slug and project+session id.
3. Implement inbox submission with required-field validation.
4. Implement slug de-collision: same-agent pending updates require matching provenance; other pending collisions allocate slug--agent, then availability-checked numbered candidates.
5. Implement inbox list filters by status, type, and agent, defaulting to pending.
6. Implement transactional, authorized promotion from inbox entry to an approved active decision.
7. Implement rejection as a retained status transition.
8. Implement direct decision creation and decision updates, including supersession links.
9. Implement agent memory recording with verified provenance, pending trust, and normalized comma-delimited tags.
10. Implement memory search with whole-tag matching and agent-specific retrieval.
11. Implement session start/update/current semantics with one open current session.
12. Implement a deterministic context compiler: approved decisions first, then eligible bounded memory, then current session, all inside an explicitly untrusted data envelope.
13. Implement DTO-based export to .squad/ and .agentweaver/context/.
14. Implement import from .squad/decisions/inbox/*.md as a non-destructive union.
15. Refresh mirrors after decision/inbox mutations and post-run Scribe processing; keep agent-memory recording latency independent of filesystem export.
16. Add a post-run Scribe path that auto-merges only low-risk entries attributable to the exact completed run and reports higher-risk entries for review.
17. Add a verified Coordinator finalization backstop for its own run-scoped architectural and scope entries.
18. Migrate unverifiable existing rows as legacy and require explicit approval before compilation.
19. Ensure backup and migration plans include the memory database, not only the operational database.

Common gotchas

• The decision inbox is not disposable scratch space; it is part of the audit record.
• A pending inbox file is not the source of truth after export; the database row is.
• Same slug does not always mean same proposal. Different agents can choose the same words for different ideas.
• Same-agent idempotence should stop at merged or rejected entries.
• Auto-merging should be conservative. Low-risk learnings are not the same as architectural boundaries.
• A cross-team tag is not approval.
• An active database status is not enough for a legacy decision to compile.
• Prompt context order is policy: decisions before memory before session.
• Exported .agentweaver/context/* files are generated context artifacts, not the canonical decision store.
• Import that overwrites existing rows by slug can destroy review history; import should add missing pending items only.
• A file mirror that cannot represent two entries with the same slug is why de-collision exists.
• Backups that omit memory.db omit the team's governance history.

Diagram details and constraints

Element	Contract
title	Context is selected data, not instructions
takeaway	Approved decisions, jointly ranked memories and the open session converge into untrusted JSON.
group-title0	SCOPED INPUTS
group-title1	SELECTION AND SERIALIZATION
Active decisions	Active decisions
Active decisions	Project-wide boundaries
Active decisions	Approved architecture / scope
Active decisions	Oldest-created first
Active decisions	Child prompts: decisions plus task-relevant memory
Core + learnings	Core + learnings
Core + learnings	Agent-scoped candidates
Core + learnings	Core: exclude legacy trust
Core + learnings	High learning / pattern
Core + learnings	Approved cross-team allowed
Open session	Open session
Open session	Latest active session
Open session	Focus / issues / summary
Open session	Ended sessions excluded
Open session	Latest StartedAt wins
Joint rank + budget	Joint rank + budget
Joint rank + budget	One combined memory list
Joint rank + budget	Task relevance, importance, then recency
Joint rank + budget	Stop at item / char limit
Joint rank + budget	Approximation: 4 chars/token
Context compiler	Context compiler
Context compiler	Assemble scoped sections
Context compiler	Decisions + selected memory
Context compiler	Add current session
Context compiler	Empty inputs → null
Untrusted JSON	Untrusted JSON
Untrusted JSON	Historical data, not authority
Untrusted JSON	Explicit boundary markers
Untrusted JSON	Ignore embedded instructions
Untrusted JSON	untrusted-context.v1
relation-0	1 combine / sort
relation-1	2 approved
relation-2	3 latest open
relation-3	4 selected
relation-4	5 serialize
assurance	Defaults: 20 memory items / ≈4,000 tokens. That budget bounds selected memories—not decisions or the entire context.
assurance-0-label	Joint memory ordering
assurance-0-fact	Task relevance first; importance and recency break ties.
assurance-0-source	MemoryContextCompiler.cs
assurance-1-label	Bounded selection
assurance-1-fact	Item / character limits cover memory.
assurance-2-label	Injection resistance
assurance-2-fact	Context is wrapped as untrusted JSON.
assurance-2-source	MemoryContextCompilerSecurityTests.cs
n0	Approved architecture / scope; Oldest-created first
n1	Core: exclude legacy trust; High learning / pattern
n2	Focus / issues / summary; Ended sessions excluded
n3	Task relevance, importance, then recency; Stop at item / char limit
n4	Decisions + selected memory; Add current session
n5	Explicit boundary markers; Ignore embedded instructions
groups	SCOPED INPUTS; SELECTION AND SERIALIZATION

Diagram details and constraints

Element	Contract
title	From proposals to usable context
takeaway	Verified authorship and trust gates control selection; selected content remains untrusted data.
group-title-0	AUTHORED PROPOSALS
group-title-1	GOVERNANCE ALTERNATIVES
group-title-2	ELIGIBILITY AND PROMPT BOUNDARY
Resolve authorship	Resolve authorship
Resolve authorship	Human or verified run
Resolve authorship	exact project scope
Pending inbox	Pending inbox
Pending inbox	Persist source provenance
Pending inbox	decision proposal
Pending memory	Pending memory
Pending memory	Validate type and importance
Pending memory	source + pending trust
Authorized promotion	Authorized promotion
Authorized promotion	Owner / verified Coordinator
Authorized promotion	transactional decision
Authorized rejection	Authorized rejection
Authorized rejection	Retain rejected inbox row
Authorized rejection	history is not deletion
Scoped Scribe path	Scoped Scribe path
Scoped Scribe path	Only eligible low-risk entries
Scoped Scribe path	same run + time window
Approved boundaries	Approved boundaries
Approved boundaries	Active architecture / scope
Approved boundaries	approved trust required
Memory + session	Memory + session
Memory + session	Non-legacy; cross-team gated
Memory + session	bounded memory selection
Untrusted JSON	Untrusted JSON
Untrusted JSON	Eligibility is not authority
Untrusted JSON	data, not instructions
e0	submit
e1	record
e2	approve
e3	reject
e4	eligible
e6	filter
e7	serialize
groups	AUTHORED PROPOSALS; GOVERNANCE ALTERNATIVES; ELIGIBILITY AND PROMPT BOUNDARY

Diagram details and constraints

Element	Contract
title	Allocate an inbox slug safely
takeaway	Update only a matching pending author; numbered candidates must be checked again.
group-title-0	REQUESTED IDENTITY
group-title-1	UPDATE OR ALLOCATE
group-title-2	AVAILABILITY LOOP AND INSERT
Verified submission	Verified submission
Verified submission	Project + requested slug
Verified submission	authorized author
Requested slug exists?	Requested slug exists?
Requested slug exists?	Look up within project
Requested slug exists?	project / slug
Same-agent terminal?	Same-agent terminal?
Same-agent terminal?	Merged or rejected replay
Same-agent terminal?	explicit conflict
Pending match?	Pending match?
Pending match?	Same agent, kind, identity
Pending match?	SourceKind + identity
Update existing	Update existing
Update existing	Preserve proposal identity
Update existing	idempotent pending edit
Allocate candidate	Allocate candidate
Allocate candidate	Slug plus agent segment
Allocate candidate	slug--agent
Candidate available?	Candidate available?
Candidate available?	Check every numbered slug
Candidate available?	repeat the lookup
Increment suffix	Increment suffix
Increment suffix	Try the next candidate
Increment suffix	--2, --3, ...
Insert pending	Insert pending
Insert pending	Unique project/slug backstop
Insert pending	racing insert may fail
e0	lookup
e1	absent
e2	exists
e3	pending
e4	match
e5	different
e6	other
e7	test
e8	occupied
e9	recheck
e10	free
groups	REQUESTED IDENTITY; UPDATE OR ALLOCATE; AVAILABILITY LOOP AND INSERT

Diagram details and constraints

Element	Contract
title	One authority, asymmetric exchange
takeaway	The store exports several views; only inbox Markdown imports as pending proposals.
group-title-0	AUTHORITATIVE STORE AND POLICY VIEWS
group-title-1	OPERATIONAL FILE VIEWS
group-title-2	PATTERNS AND THE NARROW IMPORT PATH
Memory store	Memory store
Memory store	Provider-neutral authority
Memory store	SQLite: memory.db
Approved decisions	Approved decisions
Approved decisions	Active decisions only
Approved decisions	decisions.md
Approved boundaries	Approved boundaries
Approved boundaries	Architecture / scope only
Approved boundaries	boundaries.md
Pending inbox files	Pending inbox files
Pending inbox files	Rewrite current pending set
Pending inbox files	decisions/inbox/*.md
Agent history	Agent history
Agent history	Eligible learning / updates
Agent history	agent history.md
Current session	Current session
Current session	Latest open session only
Current session	identity/now.md
Approved patterns	Approved patterns
Approved patterns	Pattern memories only
Approved patterns	patterns.md
Inbox parser	Inbox parser
Inbox parser	Parse; skip malformed files
Inbox parser	not a general file sync
Missing-slug proposal	Missing-slug proposal
Missing-slug proposal	Existing slugs stay intact
Missing-slug proposal	pending, not approved
e0	export
e6	inbox
e7	missing
e8	persist
groups	AUTHORITATIVE STORE AND POLICY VIEWS; OPERATIONAL FILE VIEWS; PATTERNS AND THE NARROW IMPORT PATH

Visual model

Context compilation and progressive tool disclosure

Structured source · Editable draw.io