A Promotion Queue: Routing Draft Writes to a Second Source Check

Putting the check inside the writer is the most common shortcut and it fails for three reasons. The writer's credentials usually narrow the answer: a service account scoped to one tenant, one workspace or one environment reads a cached or filtered view. The writer's process shares state with itself: connection pools, request-scoped caches and in-process memoization return the value it just wrote. And the writer's rate limit is the writer's, so a burst of drafts cannot be checked at a different pace than they were produced.

The checker should therefore hold a read-only credential on the second source, have its own rate limit budget, and expose one narrow interface: given a claim (subject, field, asserted value, scope), return the observed value, a read time, and a source identifier. Nothing else. A generic "verify this" endpoint invites the checker to become a second writer.

This is the same principle the memory literature calls controlled writes: one application-owned path decides what enters durable memory, and the model proposes while application code decides (Zep). It also matches the pattern atlas's insistence that evidence be preserved before belief, so that correction is possible later (Agent Memory Atlas). A queue row is evidence. The promoted value is belief.

There is a practical side benefit. Once the checker is a service, you can rate-limit it per source and per time window, which is precisely the countermeasure against flooding and fake corroboration that Zep describes. A claim that arrives fifty times in a minute hits the same per-source budget whether it came from one account or fifty.

The second source can be correct and still useless. Its read has an age, and that age matters more than the draft's age, because the read is what you are about to trust. This is the distinction the queue enforces: the cutoff is a maximum age for the second source read, measured from check time backward to the read time, not from draft time forward.

A worked example makes the arithmetic concrete. Suppose the cutoff is 24 hours.

Row two is the case that separates the two clocks. The draft is more than a day old, but so is the read, and the read is the thing that has gone off. If you had measured from draft time, row four would have been dropped for a draft that was 38 hours old even though its verification was four minutes old.

The cutoff number itself should come from how fast the second source changes, not from taste. If the second system of record is updated by a batch job every few hours, a 24 hour cutoff tolerates several missed batches and is probably too loose. If it is updated continuously, 24 hours is generous. Set the cutoff so that a read at the boundary is still likely to match what a fresh read would return, and write that reasoning into the queue's configuration so the next person does not have to guess.

Forgetting research makes the same point from the other direction: staleness is a recall-quality problem, not a storage problem, and age-based expiry is the crudest of the four eviction strategies, right for policy-bound data and wrong for facts that stay true (mem0 on eviction and forgetting). A staleness cutoff is an age policy applied to a read, and it should be paired with a reason code so you can see how often it fires.

Note also what a TTL on the second source does and does not guarantee. The MongoDB agent-memory documentation is unusually honest here: deletion is not immediate, and a retention change that silently fails leaves data expiring on the old schedule (configure TTL). If your checker reads from a store with its own retention policy, a missing value is ambiguous. Record "no read" as a distinct verdict, not as a mismatch.

Every draft that enters the queue produces exactly one row, and the row is the audit record. The minimum field set:

Two of these deserve emphasis. Reason codes must be a closed enumeration, not free text, or you cannot aggregate them and the queue becomes a log rather than a control. And actor should be able to name a rule, not just a person, so that an automatic promotion by rule.independent_match.v3 is distinguishable from a reviewer's override. Microsoft's audit activity tables show the same shape at platform scale: an agent tool call, an inference call and a guardrail application are separate, named operations (Microsoft Purview audit activities).

A compact reason code set that has held up in practice:

PROMOTE_INDEPENDENT_MATCH      both values equal, source fresh, different credentials
PROMOTE_SCOPED_MATCH           equal within the draft's declared scope only
DROP_CONTRADICTED              source B differs and is fresh
DROP_STALE                     source B read older than cutoff
DROP_NO_READ                   checker returned no value
DROP_SCOPE_MISMATCH            source B answered for a different scope
NEEDS_REVIEW_AMBIGUOUS         values comparable but not equal (format, units, rounding)
NEEDS_REVIEW_HIGH_IMPACT       rule flags this field for human sign-off
NEEDS_REVIEW_CHECKER_ERROR     checker failed; not evidence either way

The decision enum collapses to promote, drop or needs_review, which is the same three-way policy GovMem uses. Keeping needs_review as a first-class outcome is what makes the review burden measurable rather than invisible; GovMem reports it explicitly, at 0.692 in its human-labeled subset (GovMem).

Read time and decision time are separate columns for the same reason event time and acceptance time are stored apart in defensive memory design: a later date does not make a claim more trustworthy, and collapsing the two clocks hands an attacker the lever (Zep).

Intake. The writer does not decide. It enqueues a draft with its scope, its asserted value and a typed subject. The queue is append-only; a resubmission of the same claim is a new row that references the original, which gives you the dependency information you need to spot fifty copies of one source.

Check. The checker reads source B, records the value and the read time, and returns. It does not compare, decide or write anything durable. This keeps the checker cheap to test and impossible to blame for a bad promotion.

Evaluate. The queue applies rules in a fixed order: scope mismatch, then staleness, then value comparison, then impact flags for needs_review. Fixed order matters because a stale read that contradicts must never be reported as a contradiction.

Record and act. The row is written before the promoted value is written to long-term memory, so a crash leaves an orphan row you can replay rather than a silent promotion with no record. Replay is idempotent on draft_id.

Review. Needs_review rows go to a human with the row, not with a paragraph of model prose. The reviewer's actor id lands in the same table.

The compliance case for the extra ceremony is straightforward. SOC 2's Security criterion expects logging and monitoring as primary evidence, with audit logs retained beyond the lifetime of the systems that produce them and stored in tamper-evident archives, and Type II reports cover an observation period of typically six to twelve months (SOC 2 logging pipelines). A table that answers who, what, when, why and what the value was before is exactly the artifact that question requires (audit logs in data platforms).

Before you build, write the capacity numbers down. If the writer produces 10,000 drafts a day and the checker can read 4,000 claims an hour, the queue will fall behind by design unless you batch by subject and field. Batching is fine as long as read_time reflects the batched read, not the batch start.

If your agent fleet already spans several model providers and you are wiring the checker to compare model-authored claims against a source of record, Quanta Inference gives you one OpenAI-compatible key and US-dollar prepaid pricing across text, image, video, audio and embedding models, which keeps the checker's model dependency out of its credential story.

Three failure modes are worth naming because each has a detectable signature.

The checker that echoes. If source B is populated by the same pipeline that produced the draft, promotion rates will look excellent and mean nothing. Detection: measure the rate of DROP_CONTRADICTED. A healthy independent source contradicts sometimes. A zero rate on a large sample is a warning.

The staleness verdict that never fires. If DROP_STALE is never emitted, either your checker is fast or your cutoff is not being evaluated against read_time. Log source age as a histogram on every row and check the tail.

The review queue that becomes a rubber stamp. Needs_review rows resolved in under a few seconds, consistently, by one actor, indicate that the human step is decorative. GovMem's external coding-agent adjudication is a sobering reference point: none of 133 high-impact candidates were safe for automatic promotion (GovMem). If your approval times look like that dataset, assume the same.

One more: recorded decisions age. A promoted value with a fresh check six months ago is not evidence of anything today. Give promoted values their own age column and re-queue them at a slower cadence, so the queue is also the mechanism for catching drift rather than only for catch-and-release at write time.