Skip to content

Provider Memory & Evidence Reuse

How ProcureGraph remembers what it has already measured — so a mission doesn't pay to learn what a prior mission already proved. This is both a cost lever and the foundation of the product's long-term moat.

The idea in one paragraph

Every audition ProcureGraph runs produces a provenance-stamped, measured fact about a provider: its quality on a real task, at a known cost, verified against a holdout. Those facts don't evaporate at the end of a mission — they become provider memory. When a later mission needs the same evidence, it can reuse the earlier measurement instead of paying to re-measure. The result: the first mission pays to learn; every subsequent mission benefits for free — and ProcureGraph accumulates a proprietary dataset of who actually performs.

This is deliberately not generic "chat memory." It is not embedding-similarity recall of free-floating text. It is reuse of verified, source-linked, trust-tiered evidence — the same discipline the rest of the system uses for money, applied to what the agent learns.

How it works

The read path — evidence planning

Before a mission buys auditions, plan_evidence asks: do we already have fresh, trustworthy evidence for these providers? If yes, it decides reuse instead of run_audition, and the mission skips straight to selection with zero benchmark spend. The decision itself is ledgered with its provenance, so "we reused" is as auditable as "we measured."

The reuse policy (deterministic, fail-closed)

Whether a prior measurement may be reused is decided by an explicit, unit-tested policy (evidence_reuse_policy.py) over candidate rows returned by a query (provider_evidence_queries.py) — never by the model. The rules:

  • Trust tier gate. Only measured_production and measured_trial evidence qualifies. A provider_claim can never be reused as if it were measured — that is the anti-poisoning guarantee, identical to the selection-time trust model.
  • Freshness window. Evidence older than a bounded window (a documented constant) is stale and does not qualify — providers drift, so old measurements expire.
  • Exact match. The candidate must match the task profile and provider set; partial matches do not qualify.
  • Verified source. The evidence must come from a completed, verified prior mission with real audition rows and event-sequence provenance.
  • Fail-closed. Absent, stale, or ambiguous data means run the audition — reuse is only ever chosen when the evidence positively qualifies.

Provenance

A reuse decision carries a full provenance record into the ledger: the prior mission id, the specific audition ids, their evidence classes, and the event sequence numbers they came from. Reused evidence flows into selection with its origin labelled in the scoring breakdown, so a selection built on reused evidence is just as traceable as one built on fresh auditions.

Why it matters — the two payoffs

1. Cost collapses as the dataset grows. The first mission to evaluate a provider pays the audition fee; the hundredth reuses it for free. Diligence that starts as a per-mission cost trends toward a fixed, amortised asset.

2. It is the moat. Every audition is proprietary data on which providers actually deliver versus which ones only claim to. Over time that becomes the authoritative performance record for AI providers — a reputation layer that a competitor cannot copy by cloning the UI, because they don't have the measured history. Provider memory is the bridge from "audition every time" to "own the standard everyone else has to reference."

What it is and isn't (honest scope)

  • It is: deterministic, provenance-stamped reuse of verified, trust-tiered audition evidence across missions, wired into evidence planning and selection, opt-in and fail-closed.
  • It is not: a generic memory layer, embedding-similarity recall, or anything that lets a provider's claims accumulate trust. Those approaches are poisonable and unauditable; this one extends the system's existing evidence discipline rather than bolting on a separate, weaker trust model.
  • Roadmap: richer context fingerprints, bi-temporal "what did we know as of the decision date" queries, consolidation and decay of the stored record, and governance controls — all building on the same source-linked, fail-closed foundation.

Where it lives in the code

  • application/procurement/plan_evidence.py — the reuse-vs-audition decision on the read path.
  • application/procurement/evidence_reuse_policy.py — the deterministic qualification policy.
  • application/ports/provider_evidence_queries.py — the consumer-driven query port.
  • infrastructure/db/queries/provider_evidence_queries.py — the query implementation over the auditions and outcome-verification records.