Palace Semantic Memory Contract

Source basis: Palace of Truth memory REST/MCP schemas, semantic memory services, retention service, and reflection contract, reviewed through commit 62b4328 on July 9, 2026.

Palace exposes a canonical memory facade for agent runtimes that need durable context without hardcoding tenant assumptions or mixing private agent memory into a shared vector pool.

Canonical Entry Contract

First-class semantic memory entries preserve:

• stable entry and source identifiers;
• scope_type and scope_key;
• source and provenance metadata;
• created_at, valid_from, optional valid_until, and optional supersession lineage;
• fact_kind such as world, experience, or observation;
• tags, idempotency keys, and relationship policy;
• canonical content plus derived search fields.

Use valid_at for historical recall. Current facts outrank superseded facts by default. Temporal fields organize what Palace knew and when; they do not prove that a fact is objectively correct.

Core REST Contract

• GET /api/v1/memory/whoami resolves authenticated tenant identity.
• POST /api/v1/memory/entries accepts one durable scoped memory.
• POST /api/v1/memory/entries:batch accepts up to 100 entries with ordered per-item durability results.
• POST /api/v1/memory/retrieve retrieves one explicit scope.
• Routed agent retrieval can select authorized agent, workspace, session, and shared scopes without silently broadening access.
• Memory-job listing and retry APIs let operators inspect and recover failed writes.
• Bulk writes can defer relationship extraction and queue bounded backfill work.

Strict Semantic Recall

The current semantic contract is designed around ten public behaviors:

1. strict agent and workspace scope isolation;
2. typed provenance on recall hits;
3. caller identity and scope sovereignty;
4. mission-aware retention;
5. empty recall without fabricated context;
6. source-backed or raw memory preference for source-sensitive queries;
7. no private-agent leakage during workspace collisions;
8. multi-source results with per-hit provenance;
9. deterministic item and context budgets;
10. current-versus-superseded ordering plus valid_at recall.

Per-scope profiles can configure retain_mission and quiet_recall without rewriting stored memories.

Durability And Duplicate Replay

A 202 memory write means Palace accepted a durable item/job before background work. Clients should retain job_id, follow poll_url, and respect retry/backpressure metadata rather than rewriting the body blindly.

Idempotent replays return typed duplicate metadata. A duplicate response is not a failed write and should not create another durable memory.

Retention And Reflection

Retention extracts candidate durable facts under the configured scope mission and writes through the canonical admission path. It is distinct from semantic recall.

Reflection is a separate opt-in operation and is disabled by default. It creates candidate_memory_reflection curation artifacts with source IDs, source digests, provenance state, and conflict metadata. These candidates remain generated_unpromoted, do not appear as canonical semantic recall, and cannot outrank raw or source-backed memory until reviewed and promoted through an allowed workflow.

Unresolved contradictions block promotion. Palace does not claim that generated reflection is autonomous truth consolidation.

Source And Claim Governance

Wakeup context and decision-claim workflows can expose source support, stale-source invalidation, operator review history, and answer audit. These are bounded trust controls, not a guarantee that every generated answer has complete proposition-level support or that every downstream artifact is automatically invalidated.

Operator Intent

Use the contract for agent memory, trust-aware startup, Control Tower recovery, and tenant-scoped runtime support. Evaluate semantic quality against a defined corpus and failure model. Keep production deletion, cleanup, restore, and admin credential operations human- and operator-led.