Salience and Beacon (design stage)

Salience is the discipline of selecting the right context, in the right amount, at the right moment. Beacon is the name for a future delivery mechanism (design stage, not shipped) 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 without a salience score, a reranker, or a relevance sort, and nothing on this page changes that. Its recent-call history is ordered newest call first, up to five, and is not ranked by relevance. Governed facts, where they are served, are optional additive fields described in What recall gives you back. 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

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 server, not a client, would own a cap on 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, with a context_audit_id taken from a recall_and_enrich response; that id is present only when the voice feedback loop is enabled for your deployment, and the context path supplies none.

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.