Intelligence Gating

Intelligence gating is a pre-embedding filter that runs on every POST /memory/add request. Before the platform spends compute on embedding and indexing a memory, the gatekeeper scores the incoming content and compares it against the project’s configured threshold. If the score falls below that threshold, the memory is persisted with status: gated and is never embedded — it exists in the database for audit purposes but does not enter the vector index and cannot be recalled.

Every memory passes through a deterministic, multi-step pipeline before dispatch:

1. 1Importance scoring. The importance scorer evaluates the content across seven weighted dimensions (recency, frequency, content type, source trust, size, density, plan tier) and produces a deterministic 0–100 score.
2. 2Threshold comparison. The score is compared against the project-level gating threshold (default: 0.30). Memories at or above the threshold pass; memories below are flagged for gating.
3. 3Quota check. Before any work is dispatched, the platform verifies the organization is within its plan quota. If the monthly quota has been exhausted, the request returns a successful empty response and never reaches the gatekeeper. See Silent Degradation.
4. 4Dispatch or skip. Accepted memories proceed to embedding and vector indexing. Gated memories are committed with status: gated and an audit record.

The gatekeeper is budget-aware: it checks per-project embedding quotas before dispatching a memory for embedding. This is the critical integration point between the intelligence engine and the billing layer.

Certain conditions cause the gatekeeper to skip scoring and dispatch immediately:

• Bypass sources. Sources configured as bypass sources for the project (e.g. support_ticket, critical_alert) always pass regardless of score.
• Force flag. When the caller sets a force-ingest flag on the request, scoring is bypassed entirely.
• Admin override. Organization admins can disable gating at the project level, causing all memories to pass through.
• Re-evaluation promotion. When the re-evaluation engine re-scores a previously gated memory above the threshold, it is dispatched for embedding automatically.

A gated memory has a well-defined lifecycle that preserves auditability:

1. 1Persisted. The memory row is committed to the database with status: gated. The raw content, metadata, and source attribution are all preserved.
2. 2Not embedded. No vector is generated. The memory has no vector_id and cannot appear in recall results.
3. 3Auditable. The gating decision is recorded in the audit log with the score, threshold, and reason.
4. 4Promotable. If the re-evaluation engine later re-scores the memory above threshold, it is automatically promoted, embedded, and indexed.

Every gating decision emits structured signals for observability:

• Audit log entries. Each gated memory creates an audit record tagged with the engine name, the computed score, the threshold, and the outcome (dispatched or gated).
• Quota-driven skips are tracked separately. When a request is silently skipped because the organization has exhausted its plan quota, the event is recorded in the internal usage telemetry so dashboards can distinguish quota-driven skips from quality-driven gating.
• Per-project metrics. Counters track total runs, gated count, dispatched count, and skip count per project. These feed the project-level analytics dashboard.

• Importance Scoring — the seven-dimension scoring formula that produces the score the gatekeeper evaluates.
• Re-evaluation Engine — feedback loops that can promote previously gated memories.
• Silent Degradation — the response contract when plan-quota exhaustion triggers a silent skip.
• Billing Usage — every gating decision is reflected in your organization’s billing metrics.