symfonic.capabilities.memory.admin¶
admin ¶
Memory administration, scoped, as operations rather than objects.
Generated projects administer memory through operations, not private layers.
Operations, never the store. Handing out a layer makes every consumer invent its own idea of what a scope means, and three consumers doing that is how one tenant ends up reading another. Every method here takes a scope and honours it; there is no accessor that returns the thing underneath.
Staged rows are invisible here, and that is the point. An operator acting
on a pending row would be acting on something the turn may still discard. The
admin view shows what is committed; discard and publish are how staging
is resolved, and they are named as the two different things they are.
MemoryAdminService ¶
Read, resolve and erase one scope's memories.
One service per process, not per scope: the scope is an argument to every
method, because an administrative caller acts on scopes it is authorised
for rather than on the one it was built with. That is the opposite of
:class:MemoryCapability, which IS a scope -- and the difference is real:
a capability serves one agent's turns, this serves an operator's request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
store
|
Any
|
an HMS satisfying the retrieval, write and lifecycle ports. Held privately and never returned: a service that exposed it would be a slower way to reach the layers. |
required |
Source code in src/symfonic/capabilities/memory/admin.py
procedural_review_available
property
¶
Whether this service was composed with the procedural review door.
approve_procedure
async
¶
approve_procedure(scope: MemoryScope, procedure: Any, *, action_tool: str | None = None, precondition: Any = None) -> Any
Approve one draft, and record what a reviewer decided it governs.
Approval is the review, so this is where a tool and a precondition are named. That is not a convenience: the offline extractor reads what a scope did and has no way to know which registered tool a narrated action corresponds to, or what state must hold before repeating it. A draft it wrote governs nothing until a person says what it governs -- which is what makes "draft" the right status for it and human review the quality gate rather than a formality.
Both arguments are optional, so approving a procedure that only informs the prompt stays one call.
Source code in src/symfonic/capabilities/memory/admin.py
correction
async
¶
correction(scope: MemoryScope, record_id: str, text: str, fields: Mapping[str, Any], *, salience: float = 0.9) -> MemoryRecord
Record that a person corrected their own profile. Staged, not published.
The named door for user_manual_edit. Phase 5 promotes a memory
carrying that authority onto the scope's profile on the next nap, so
the value is a grant rather than a description -- and a grant an
extractor could mint by putting a string in its metadata bag would be
no grant at all. MemoryRecord refuses it from metadata and
accepts it only on its own field; this is where a deployment sets that
field without writing the vocabulary out by hand.
Staged rather than published for the same reason every other write
here is: a correction that failed halfway should leave nothing, and
publish is the step that makes it retrievable.
Returns the record so a caller can name it in a receipt or a log.
Source code in src/symfonic/capabilities/memory/admin.py
delete_record
async
¶
Exact-owner storage operation; platform callers must audit first.
Source code in src/symfonic/capabilities/memory/admin.py
discard
async
¶
forget
async
¶
Erase scope and everything below it, staged and committed alike.
The operation a deletion request needs, and deliberately not
discard: a privacy request that had to go through discard would
depend on whether a turn happened to have finished. Idempotent -- an
empty scope answers with an empty receipt rather than raising, because
"there was nothing to erase" and "the erasure failed" must not look the
same to a caller acting on a deletion request.
Source code in src/symfonic/capabilities/memory/admin.py
get_record
async
¶
Direct published-record lookup, without a retrieval-page ceiling.
Source code in src/symfonic/capabilities/memory/admin.py
inventory_page
async
¶
Published records in ID order; continuation is independent of recall.
Source code in src/symfonic/capabilities/memory/admin.py
procedures
async
¶
What this scope has learned, for a reviewer to read.
Drafts included by default: this is the review queue, and a queue that hid what was waiting on review would be a queue with nothing in it.
Source code in src/symfonic/capabilities/memory/admin.py
publish
async
¶
record_page
async
¶
record_page(scope: MemoryScope, *, layer: MemoryLayer | None = None, limit: int = DEFAULT_PAGE) -> RetrievalResult
Bounded admin records with explicit drops and incomplete-scan signals.
Source code in src/symfonic/capabilities/memory/admin.py
records
async
¶
records(scope: MemoryScope, *, layer: MemoryLayer | None = None, limit: int = DEFAULT_PAGE) -> tuple[MemoryRecord, ...]
Committed memories scope may read: its own and its ANCESTORS'.
Reading widens upward, never downward; erasure walks the opposite
direction. layer narrows that visibility and cannot grant access.
Use record_page when omission/completeness evidence is required.
Source code in src/symfonic/capabilities/memory/admin.py
reject_procedure
async
¶
Reject one draft. It stays readable and stops being active.
Source code in src/symfonic/capabilities/memory/admin.py
stage
async
¶
Prepare records under scope. Nothing is durable until publish.
Exposed because an administrative import is a real operation and the alternative is a caller writing straight to the store, which is the access this service exists to replace.