Salience and Beacon

DESIGN STATE — NOT A SHIPPED CAPABILITY. Northsun (formerly Mnemix) ships a frozen caller REST surface, a hosted MCP endpoint, and source-defined MCP tools today. A complete authenticated production MCP lifecycle has not been re-proved for this release. Proactive salience, Beacon delivery, SSE push, demand tiers, consent controls, frequency caps, and a proactive UI remain governed design work until their runtime and proof gates graduate.

Salience is the discipline of selecting the right context, in the right amount, at the right moment. Beacon is the codename for a future delivery mechanism that would surface governed context without requiring the agent to formulate the perfect recall query first.

Northsun remains the memory and enrichment layer for AI agents. Governed context intelligence is the differentiator: Every agent proposes. Northsun governs.

What exists today

• The frozen caller REST surface: recall_and_enrich, calls/end, and caller/{phone_number}.
• A hosted MCP endpoint and source-defined tools for caller, contact, and evolving context workflows; authenticated production lifecycle proof remains a release gate.
• Governed records and retrieval concepts described in Evidence references, Locked facts, and Bi-temporal validity.

These surfaces are reactive: an application or agent asks for context or records an interaction. Their existence does not prove proactive Beacon delivery.

The frozen caller read is not salience-ranked

recall_and_enrich returns stored caller memory in two parts, and neither is a relevance ordering. It does not apply a salience score, a reranker, or a relevance sort, and nothing on this page changes that.

• Standing facts. A memory the extractor recorded as having exactly one correct current answer for that person — a home address, an authorized contact, an access requirement — is returned whether or not it is recent. These are capped in number, and a superseded value is never returned: storing a new value for the same fact retires the old one at write time.
• Everything else is returned in recency order, most recently updated first.

The split is by how a fact was recorded, not by how important or relevant we judge it to be. Everything below describes design work for a future proactive path; none of it governs the frozen three-endpoint contract. If your integration needs a different ordering, filter or sort the returned items in your own application.

What Beacon is intended to add

The design separates context intelligence from delivery:

signals
  -> arithmetic salience scoring
  -> consent, privacy, policy, and frequency gates
  -> server decision: silent | fast_intervention | full_assistance
  -> future MCP subscriber or SSE delivery
  -> acceptance / dismissal / contradiction feedback

The server—not a client, SDK, MCP host, or agent prompt—would choose the demand tier. A client may render an allowed result, but it must not recreate the salience formula or bypass a silent decision.

Intended demand tiers

Tier	Intended behavior
silent	Produce no user-visible proactive surface.
fast_intervention	Offer a compact, provenance-backed memory or hint.
full_assistance	Offer a richer context package only when evidence, confidence, consent, and frequency policy allow it.

These names are a design contract, not fields available from a public endpoint today.

Design invariants

• Arithmetic hot path: no LLM or provider SDK in inline salience scoring.
• Evidence on non-silent output: a future surfaced item must carry provenance.
• Separate consent: permission to store memory is not permission to push it proactively.
• Default off: proactive output begins disabled per tenant.
• One-action kill switch: operators must be able to stop all proactive output.
• Server-owned frequency cap: the design starts at no more than three proactive surfaces per session.
• Deletion before delivery: tombstoned or disallowed data must not surface.
• Current storage: pgvector/Postgres remains the day-one design; Qdrant is a measured scale trigger, not a prerequisite.

These are acceptance requirements for a future implementation. They are not a public compliance certification or production-performance claim.

What you can evaluate now

Use the frozen REST loop directly. Treat the broader MCP loop as an authenticated evaluation until your tenant proves it end to end:

1. Call recall_and_enrich before a voice interaction when caller identity is available.
2. Authenticate to the hosted MCP endpoint, run tools/list, and confirm the enabled tools and tenant scope before calling context.
3. If ingestion and context tools are enabled, run one controlled observe-to-context proof and verify that the same tenant and test subject are preserved.
4. Exercise feedback only when it appears in the authenticated tool list, then prove the complete observe → context → feedback lifecycle before making it a production dependency.

The frozen caller REST loop can be built against today. The broader MCP sequence is an evaluation procedure, not a production-support claim. Neither may be labeled Beacon. Do not create /v1/beacon/* calls, claim an SSE stream exists, or advertise proactive delivery from the current tool list.

Failure modes the design must defeat

• Interruption overload: too many correct memories still make a bad product.
• Stale authority: the newest fact is not automatically the governing fact.
• Memory poisoning: untrusted tool output must not silently become behavioral instruction.
• Consent collapse: storage permission must not be reused as push permission.
• Client divergence: different agents must not invent different salience decisions.
• Non-observable silence: operators need proof that suppression and kill switches work.
• Deletion resurrection: derived context, caches, and projections must not re-surface erased data.

Graduation evidence

Beacon becomes documentable as a shipped capability only after evidence shows all of the following on the exact deployed version:

1. Runtime scorer, privacy gates, frequency state, and surface code exist behind a default-off flag.
2. Tests observe both suppression and allowed delivery; a gate that never fails has not been proved.
3. The one-action kill switch halts delivery.
4. Tombstoned and no-push-consent fixtures cannot surface.
5. MCP subscriber or SSE behavior is product-proven, not inferred from source or a mock.
6. Acceptance, dismissal, contradiction, and interruption telemetry can be inspected without logging PII.
7. Public claims are re-reviewed against the deployed contract; no benchmark, latency percentile, customer, or compliance claim is inferred from design intent.

Privacy and consent boundary

The design requires storage consent and proactive-push consent to be separate. It also requires deletion to cover primary records, embeddings, indices, caches, and derived representations before a proactive surface is allowed. Until those mechanics are implemented and proved, Beacon should not receive real user data or be offered as an integration option.

Teardown and kill-switch design

There is no Beacon runtime to disable today. A future production teardown must:

1. Trigger the tenant or global kill switch.
2. Close MCP/SSE subscriptions without delivering queued items.
3. Cancel or drain background reflection work according to the runbook.
4. Preserve non-PII audit evidence for suppressed deliveries.
5. Remove push consent state only according to the tenant's retention and deletion policy.
6. Prove a synthetic signal produces no outward delivery after shutdown.

Next steps

• Core concepts — current memory and governance model.
• MCP server — current authenticated tools and their boundaries.
• Feedback loop — how to evaluate outcome feedback without claiming automatic learning.
• Production readiness — evidence required before launch claims.