Control Path Pipeline
Every memory operation in Memproof — whether it is aremember, update, forget, or search — passes through the same deterministic pipeline. The pipeline has six stages, each emitting an immutable event to the Audit Trail.
Pipeline Stages
Stage Details
received
The orchestrator accepts the request and generates a unique
operation_id (format: op-{hex16}). An idempotency check runs first — if the same idempotency key was already processed, the cached response is returned. The received event is emitted to the ledger with the operation’s scope.Data produced: operation_id, validated request modelrisk_assessed
The Risk Engine scores the operation across five weighted factors: operation type, PII detection, secrets detection, source trust, and scope anomalies. A separate
assess_content_flags call produces boolean flags (contains_pii, contains_secret) used by the policy engine.Data produced: RiskAssessment (score, level, factors, scorer), content flagspolicy_decided
The Policy Engine evaluates YAML rules in priority order against the operation type, risk assessment, scope, context, and content flags. The first matching rule wins, producing a
PolicyDecision with one of four actions.Data produced: PolicyDecision (action, reason_codes, matched_rule_ids, policy_version)approval_requested (conditional)
This stage only runs when the policy decision is
require_approval. The Approval Broker sends the request to an external approval system (Attesta) or queues it for manual review. Three outcomes are possible:- Synchronous approval: the broker returns immediately and the pipeline continues.
- Async/pending: the operation is stored with status
pending_approvaland the response is returned to the caller. A later call tomp.approve()ormp.deny()completes the operation. - Denied: the pipeline emits a
blockedevent and raisesApprovalDeniedError.
provider_attempted
The orchestrator delegates to the memory adapter to execute the actual backend operation (
create_memory, update_memory, delete_memory, or search_memories). If the adapter raises an AdapterError, the operation status is set to failed and a ProviderUnavailableError is raised.Data produced: MemoryRecord (on success)Operation Statuses
Each operation ends in one of these statuses:| Status | Meaning |
|---|---|
committed | Successfully persisted to the memory backend |
blocked | Denied by policy or rejected during approval |
quarantined | Held for review; payload stored in quarantine |
pending_approval | Awaiting human or system approval |
failed | Adapter error during provider execution |
Idempotency
Every mutation endpoint (remember, update, forget) requires an idempotency key. If you do not provide one, Memproof generates a random key. The idempotency check runs before the pipeline begins:
- Same key, same payload: returns the cached response.
- Same key, different payload: raises
ConflictError.
Approval Flow
When a policy decision returnsrequire_approval, pending operations can be resolved later: