Memarium FAQ

Why does Memarium need a passport?

1. Because Memarium is a constitutional organ, not a CRUD service. Memarium is not "a database with a module's data". It is the node's shared memory with four spaces under distinct constitutional policies (Personal/Community/Public/Crisis). Every entry into Memarium is a political act: "who is allowed to write to Community memory? who may read another module's Personal? who may declare a crisis?". Such an act needs a single, explicit, auditable decision point. A passport is exactly that: an externalized representation of authority that enters through the door together with the request, rather than being hidden in "who called the function in the same process". Without a passport we would have ambient authority — "if the code runs in the node, it has access" — a classical anti-pattern (confused deputy).

2. Because the operator ↔ module ↔ delegate role separation must be structural, not conventional. A passport carries fields that are vehicles for three disjoint semantics: A0 (operator) — human / node administration, wide scope, accountable as a person; A1 (local module) — Monus, Sensorium, Agora; narrow scope, accountable per module; A2 (delegate via nym) — a pseudonymous agent, accountable through the delegation chain. If we did this with a local ACL, we would have to prove on every call that "this really is Monus, not an impersonator". A signed passport bound to caller-identity shifts that proof to issuance time, while the dispatch-gate only verifies — it does not establish. The same difference as between "every room has its own lock with a key we copy by hand" and "the door checks a passport issued by a single authority".

3. Because revocable delegation is a domain requirement, not decoration. Memarium must allow: "Monus may delegate, for 24 hours, to a sub-agent the right to append to Personal for topic-class X only". Without a passport this requires either copying credentials (which cannot be revoked) or keeping per-delegation entries in a local table (which does not carry between nodes and breaks stratification). With a passport: the nym issues a delegation cert with a TTL, the target-id provides the seed for revocation, and the revocation feed (local + static + seed-directory) — the same one we already have — performs the invalidation. One mechanism across the whole node, zero duplication.

4. Because the audit-time decision must be captured at the decision point, not reconstructed post hoc. audit_decision() returns "denied:binding-mismatch" at the gate, not at log-analysis time. This means the accounting fact shares its cause with the wire response (reason: "binding_mismatch"), the correlation_id links request ↔ denial ↔ ledger entry, and a future analysis of "why was Monus denied 412 times in April" is a data query, not forensics over traces. The passport is the artefact that carries context into the decision point (caller, grant, target, scope, nonce) — without it this context is only heuristically recoverable.

5. Because stratification requires thin, stable gates. Dispatch-gate (daemon) → engine (memarium-service). The engine trusts that the gate has already authorized; the engine knows no notion of "operator", "module", "delegation". This is exactly the separation we use in Sealer (gate authorization + engine policy = allow-all-as-invariant). The passport is the gate's interface: one entry, one contract, one representation. Without a passport, every engine would have to know about all classes of caller-identity — i.e. complecting of layers in a style we actively avoid. Additionally: the same gate will serve the future community-key service and further organs — without changes in the Memarium engine. The passport scales as a concept, not as code.

6. Because portability across deployments requires concepts, not configuration. A node may run as a single-person pod, a federation relay, a server container, or a test instance. In each case "who is the operator and who is a module" is different. A passport-as-data carries between these contexts; an ACL-as-local-config-table carries nowhere. This is consistent with the principle "data as the common language, logic at the edges": the passport is data, and the policy at the gate is edge logic.

7. Because Crisis requires authorization that cannot be forged from the inside. memarium.crisis_resolve is an operation in which a module tells the node "you may return to Running". This is a classic escalation vector: a malicious/damaged module announces "all clear", the node lifts degradation, and the constitution is breached. A passport with operator-only scope on crisis_resolve makes a hard distinction here: a module may report a signal (crisis-detected via the bus, per-module), but cannot close the episode. Without a passport this distinction requires process separation (separate UIDs, sandboxes) — costly and unavailable in deployments where everything lives in a single process.

8. In one sentence. A passport is an externalized, auditable, delegable, and revocable representation of authority that lets us stratify authorization (gate) from execution (engine), preserve the A0/A1/A2 role separation, and carry the same pattern to further constitutional organs of the node. Everything else — the reason dictionary, HTTP statuses, denied:* in the ledger — are consequences of this decision, not its causes. Removing the passport would mean either ambient authority (constitutionally unacceptable) or scattering authorization logic across engines (craftsmanship-wise unacceptable).