Skip to content

Proposal 022: Monus as Host-Granted Local Observation Middleware

Based on:

  • doc/project/20-memos/orbiplex-monus.md
  • doc/project/20-memos/orbiplex-whisper.md
  • doc/project/30-stories/story-005-whisper-rumor-intake.md
  • doc/project/40-proposals/013-whisper-social-signal-exchange.md
  • doc/project/40-proposals/019-supervised-local-http-json-middleware-executor.md
  • doc/project/50-requirements/requirements-010-middleware-executor.md

Date: 2026-03-30 Status: Draft

Context

Orbiplex Monus is currently present only as a memo-level concept and as a source classification hook inside whisper-signal.v1.

That is enough to preserve semantic room for a future local wellbeing-observation module, but not enough to implement it cleanly.

The main architectural risk is splątanie:

  • local observation,
  • memory access,
  • Inquirium/model-assisted draft shaping,
  • policy enforcement,
  • and social-signal publication

could collapse into one implicit plugin if the host boundary remains vague.

Decision

Orbiplex Monus should be implemented as a supervised Node-attached middleware module, preferably through the same http_local_json attachment surface already used for bundled middleware.

Monus is not the protocol authority for outgoing social-signal publication. Instead:

  1. Monus consumes host-granted capabilities exposed by Orbiplex Node,
  2. Monus prepares local drafts, recommendations, or concern summaries,
  3. Node remains the authority that grants memory/Inquirium/signal access,
  4. Whisper remains the bounded publication layer for outgoing social signals.

Goals

  • keep Monus local-first,
  • prevent side-channel publication or hidden memory access,
  • preserve explicit responsibility boundaries between Monus, Node, and Whisper,
  • make future implementation possible without inventing a separate Monus-specific wire protocol.

Non-Goals

  • defining a new network artifact family for Monus in hard MVP,
  • making Monus itself a transport or publication authority,
  • forcing every Node deployment to include Monus,
  • freezing one specific wellbeing scoring algorithm.

Proposed Model

1. Role split

  • Sensorium or other local signal providers supply local observations.
  • Monus aggregates and weighs admitted local signals.
  • Node exposes bounded capability contracts and owns policy enforcement.
  • Whisper publishes bounded outgoing social-signal artifacts if policy allows it.

2. Host-granted capability model

Monus should consume explicit host-granted capabilities rather than ambient access to local state.

The first useful capability families are:

  • bounded local memory or read-model queries,
  • bounded local signal ingestion,
  • bounded communication-signal ingestion from user-approved communication surfaces,
  • bounded Inquirium/model-assisted draft shaping,
  • local audit/event emission,
  • request submission for Whisper-side review or publication.

Each deployment may grant a subset only.

Communication-signal ingestion is a narrower profile than general memory access. It covers local communication artifacts or read models that the user has explicitly allowed Monus to observe, such as selected outgoing messages, selected incoming messages, or derived conversation summaries. The host owns the selection policy:

  • which mailboxes, chats, contacts, accounts, or message classes are in scope,
  • whether Monus sees full content, redacted content, metadata, or summaries,
  • whether the grant applies to outgoing messages, incoming messages, or both,
  • retention and redaction rules for the observation event,
  • and whether a human review step is required before any Whisper handoff.

For example, a user may allow Monus to inspect outgoing messages as a weak signal source. If an outgoing message repeatedly names the same institution and event class, Monus may create a local candidate concern draft. That draft is a derived local artifact, not the outgoing message itself and not a network-facing rumor. The later Whisper path still performs redaction, provenance marking, budget checks, and publication policy.

3. Publication boundary

Monus may prepare:

  • a local concern draft,
  • a candidate Whisper draft,
  • or a recommendation not to publish.

But Monus should not directly push outgoing whisper-signal.v1 traffic to the network. Publication remains Node-owned and Whisper-mediated.

4. Trace and accountability

When an outgoing social signal is materially prepared by Monus, the resulting whisper-signal.v1 should preserve that provenance through:

  • source/class = monus-derived
  • or source/class = monus-sensorium-derived

The local host should also retain an audit trace that the draft was middleware- assisted rather than purely user-authored.

For communication-derived drafts, the audit trace should additionally record:

  • the communication observation grant or policy reference,
  • the source class, such as outgoing-message, incoming-message, or conversation-summary,
  • the minimum source reference needed for local audit or appeal,
  • whether Monus saw raw content, redacted content, metadata, or a summary,
  • the transform path from observed communication signal to candidate concern draft,
  • and the human or policy basis that allowed the draft to move toward Whisper.

The audit trace need not disclose full message content to every later consumer. It must, however, be sufficient for the local user or an authorized audit path to answer why Monus formed the candidate rumor and which host-granted capability was used.

Trade-offs

Benefits

  • preserves stratyfikacja between observation, preparation, and publication,
  • reuses existing middleware hosting work,
  • allows Monus to be implemented in Python or another language without changing the protocol core,
  • keeps the trusted host boundary small and auditable.

Costs

  • requires explicit capability contracts from the host,
  • adds one more attached-module surface to supervise,
  • leaves some Monus behavior local and implementation-defined until later requirements narrow it further.

Open Questions

  1. Which local memory surfaces should Monus be allowed to query directly, and which only through pre-filtered host views?
  2. Should the first Monus baseline emit its own local draft artifact, or only in-memory middleware decisions?
  3. Which capability grants should be mandatory for a Node deployment claiming Monus support?
  4. How should acute emergency patterns be split between Monus, Sensorium, and emergency/help flows?

Next Actions

  1. Add requirements for host-granted capability contracts and publication boundaries.
  2. Add a dedicated Monus solution component under 60-solutions.
  3. Record in Node solution docs that Monus is a future supervised middleware consumer of host-granted memory/Inquirium/publication contracts.