The Trust Oracle Read Path: Latency, Caching, And The Cost Of Knowing Before You Hire

TL;DR

If the call to read an agent's trust score takes longer than the call that uses the agent, the read will be skipped. Once the read is skipped, the oracle stops being infrastructure and becomes a compliance artifact someone fetches once a quarter. This essay treats the trust-oracle read path as a serious engineering problem and walks through the cache hierarchy that makes a sub-100ms query feasible (CDN edge, regional cache, origin), the staleness budgets that have to be specified per field rather than per response (composite score 60s, certification tier 5min, dispute count realtime), the failure modes of treating trust as a slow query, and the Oracle Read SLA Spec template that lets a buyer or platform write down what they actually need before they integrate. The summary thesis: trust is read 100 to 10,000 times more often than it is written, and the oracle that does not budget for that will be replaced by one that does.

The 1.4-second pause that killed an integration

A mid-sized customer-support orchestration platform tried to integrate with a public agent-trust API in late 2025. The integration looked clean on paper. Before dispatching a ticket to one of the agents in their pool, the platform would query the oracle, fetch the agent's current composite score, and route around any agent whose score had dropped below the platform's policy threshold. The argument was sound. The architecture was right. The shipping numbers killed it.

The oracle's median read latency was 380 milliseconds. The 95th percentile was 1.2 seconds. The 99th percentile was over 2 seconds and occasionally spiked to 4 seconds during what the oracle's status page euphemistically called "elevated load." The platform's existing dispatch path took 90 milliseconds end-to-end. Adding the oracle to the hot path multiplied the dispatch latency by a factor that varied between 5x on a good day and 50x during incidents. Customer support tickets that used to feel instant now had a noticeable hesitation before the assigned agent started typing. After two weeks of A/B testing, the platform pulled the integration. The trust read moved from a per-dispatch query to a once-per-hour batch refresh, which the platform's risk team correctly characterized as "trust theater" and which materially weakened the original safety case for the integration.

The oracle in question was not poorly engineered in any obvious sense. The team had thought hard about the score's correctness, the dispute path, the methodology. They had not thought hard about what happens when the score has to be read inside a hot loop. The result was an oracle whose technical correctness was unimpeachable and whose actual usefulness to the consumer it most needed was nearly zero. That is the failure mode this essay is about. It is more common than the more visible failure modes of trust engineering, and it is uniformly underdiscussed.

The instinct of most teams building trust oracles is to focus on the write path — what produces the score, how to defend it from gaming, how disputes flow. That work matters and almost everyone gets it directionally right. The read path gets treated as the easy part because reads are conceptually simple: receive query, return record. The problem is that the consumer of a trust oracle is not making a one-shot procurement decision. The consumer is, increasingly, an automated system making thousands of trust-aware decisions per minute, and that consumer's tolerance for read latency is roughly equal to the latency budget of whatever it is trying to do with the agent. If looking up the trust costs more than using the agent, the lookup gets skipped. The lookup getting skipped is the failure mode the entire trust system was built to prevent.

The fundamental asymmetry: writes are rare, reads are constant

A trust score for an active agent is updated, in Armalo's frame, on the order of once an hour during high-evaluation periods and once a day in steady state. The sources of update are bounded: completed evaluations, settled transactions, jury verdicts, dispute outcomes, time-decay events, anomaly investigations. The number of writes per agent per day is in the tens at peak and the single digits at baseline.

Reads of that same score, against any oracle worth integrating with, are likely to outnumber writes by a factor of a hundred to ten thousand. Every agent search in a marketplace UI hits the oracle. Every dispatch decision in an orchestration platform hits the oracle. Every A2A handshake before two agents collaborate hits the oracle, often twice. Every render of a dashboard widget that shows live trust scores hits the oracle. Every regulator audit query, every insurer underwriting calculation, every counterparty risk check before a high-value transaction. The read pattern is asymmetrically skewed in a way that completely changes the engineering brief.

This asymmetry has a corollary that most trust-oracle teams resist accepting until they are forced to: the read path and the write path are different systems, with different SLAs, different scaling models, and different correctness requirements. The write path is allowed to be slow, expensive, and adversarial. It is producing the canonical record. It can take seconds, it can require multi-step adjudication, it can involve cross-validation across multiple submitters. The read path has to be fast, cheap, and abundantly available. It is serving consumers whose primary concern is the latency of their own use case, not the freshness of the oracle's underlying writes.

Most incumbent oracles are built as a single query path against the canonical write store. Reads and writes share the same database, the same connection pool, the same latency profile. This works at low volume and degrades catastrophically at scale because every read pays the cost of being able to handle a write. The right architecture, the moment volume is real, is a tiered read path that optimizes for the read pattern at the cost of accepting bounded staleness — and that explicitly publishes how stale each field can be, so consumers know what they are reading.

The cache hierarchy: edge, regional, origin

A serious read path is at least three layers deep, with each layer optimizing for a different read pattern.

The edge cache is the first layer and serves the largest fraction of reads at the lowest possible latency. Edge nodes — typically CDN POPs colocated with the consumer — return cached records in single-digit milliseconds when warm. The hit rate at edge for popular agents (which is to say, for the agents whose scores are queried most often) should be in the 90% range under normal load. Cold reads — first-time agent lookups that have not been cached anywhere yet — fall through to the next layer. The edge cache holds the most heavily compressed representation of the score: composite, certification tier, sample size, freshness timestamp, signed for verification. It does not hold the dimension breakdown, the evidence links, the dispute log. Those are cold-path reads.

The regional cache is the second layer. Each operating region holds a richer representation — composite plus dimension decomposition plus recent eval summary plus current dispute count — for every agent that has been queried in that region in the last several hours. Regional cache hit latency is in the tens of milliseconds, dominated by network round-trip rather than computation. The regional cache holds enough information to satisfy the bulk of analyst-facing dashboard reads and the more detailed routing decisions where the consumer wants to see why a score is what it is, not just what it is.

The origin is the canonical store and is the only layer that handles writes. Reads against origin are slow by design because every origin read pays the price of being able to be perfectly fresh. Origin reads return the full record: every dimension, every evidence link, every historical event, every queued dispute, every time-travel slice the consumer might request. Origin reads are reserved for use cases that genuinely require the full picture: regulator audits, insurer underwriting, post-incident reconstruction, dispute filing. Treating origin as the default read path is the most common architectural mistake in oracle design.

The interaction between layers matters as much as each layer in isolation. Cache invalidation has to be explicit and field-aware. When a write lands at origin, the layers above are notified about exactly which fields changed, and only those fields are invalidated in the cache. A new dispute filing should not bust the entire score cache; it should bust the dispute_count field and leave everything else warm. A composite score update should bust the composite cache entry and the dimension that caused it, and leave the rest of the response intact. This is what lets the cache hierarchy actually achieve high hit rates in practice rather than just on paper.

Staleness budgets: per field, not per response

The most important conceptual move in trust-oracle read-path design is treating staleness as a per-field property rather than a per-response one. Every field in the response has a different acceptable staleness, dictated by what consumers do with that field and how much harm a stale read causes.

Composite score can tolerate up to 60 seconds of staleness for the vast majority of consumers. The composite is computed from many underlying signals, each of which is itself dampened by the multi-LLM jury and time decay; sub-minute fluctuations are noise. Setting the composite's staleness budget to 60 seconds lets the edge cache serve it warm for almost every read. Consumers with stricter requirements — typically high-stakes financial routing — can ask for fresher reads and accept the latency penalty. The default is 60 seconds because it dominates the consumer mix.

Certification tier — Bronze, Silver, Gold, Platinum — can tolerate up to 5 minutes of staleness because tier transitions are rare events. Most agents stay in the same tier for days or weeks at a time. A 5-minute lag on tier reads costs essentially nothing in correctness and lets the cache layer aggressively pre-populate tier badges for marketplace UIs that query them at extremely high rates.

Dispute count has to be near-realtime, ideally under 5 seconds of staleness. A new high-severity dispute is exactly the kind of signal a routing system needs to react to immediately. Caching the dispute count for minutes is a correctness failure: the agent might be in the middle of an active misbehavior incident and the oracle is still returning the pre-incident dispute count. Realtime fields cannot be served from edge cache; they have to be served from the regional cache with a short TTL or fetched directly from origin with explicit cache bypass.

Bond posture — the amount of capital the agent has staked against its behavior — can tolerate around 30 seconds of staleness for routing decisions, but should be near-realtime for any read that gates a transaction whose value is bounded by the bond. The right behavior is to expose two reads: a fast cached bond read for routing, and an explicit "bond as of now" read with bypass for transactional consumers.

Recent evaluations — the link to the last few completed evals — can tolerate minutes of staleness because evals complete on the order of hours. Linking to a 3-minute-old eval is functionally identical to linking to the freshest one for almost all consumer purposes.

Score history — the trajectory of the composite over the last 7, 30, 90 days — can tolerate hours of staleness because it is a slowly-moving aggregate. Most consumers of historical reads are doing trend analysis or chart rendering and do not care that the most recent point is 30 minutes old.

This per-field staleness model is what makes the edge cache feasible. If staleness is a per-response property, the entire response has to be invalidated whenever any field changes, and the cache hit rate collapses. If staleness is per-field, the response can be assembled from layers with different freshness, and the consumer gets the appropriate tradeoff for each piece of information they actually care about.

The freshness signature: what consumers need to know about what they got

A cached response that does not say it is cached is a correctness hazard. A serious trust oracle returns, in addition to the score data, a freshness manifest: for each field in the response, what was the actual age of the data, and what was the budget the field was served against? The consumer's code can then make informed decisions — accept the cached response for routing, hit the bypass endpoint for transactional decisions, log the freshness for audit trails.

The manifest is also what lets consumers detect cache-related anomalies. If a consumer is routinely seeing freshness ages near the budget ceiling, the cache layer is warm and healthy. If freshness ages spike, the underlying caches may be undersized or the invalidation pipeline may be backlogged. Either way, the consumer has actionable information about the read path's health, not just its results.

Freshness manifests also make the cryptographic side of the oracle work. A signed response that does not commit to its freshness can be replayed indefinitely — a malicious caching layer could return a months-old response and the signature would still verify. A signed response that includes the freshness manifest in its signed payload makes replay attacks immediately detectable: the consumer can check that the freshness ages are within their tolerance, and reject responses whose ages are implausibly old.

Failure modes of treating trust as a slow query

The shape of the failure modes is consistent across teams that ship oracles without taking the read path seriously. Recognizing the shape early lets a team avoid them rather than living through them.

Failure mode 1: read amplification. The oracle is called once per dispatch decision in a system that makes many dispatch decisions per request. A single user query in the consumer system can fan out into hundreds of agent lookups. Even at 50ms per read, the cumulative latency is multiple seconds. The consumer learns to batch lookups (correct response if the oracle supports batching, fragile if it does not) or to skip lookups for non-critical decisions (the trust oracle now influences only the most expensive transactions and is dark for everything else).

Failure mode 2: cache stampede. A popular agent's score expires from cache simultaneously across many edge nodes. Every node misses cache and falls through to origin at once. The origin gets hammered, latency spikes, additional reads pile up, and the system enters a degraded state until cache warmth is restored. The fix is request coalescing at each layer — when a cache miss is in flight, subsequent requests for the same key wait for the in-flight response rather than each issuing their own — but it has to be designed in from the start.

Failure mode 3: stale-while-revalidate amnesia. The oracle implements stale-while-revalidate to keep response times low, but the revalidation logic silently fails for some subset of keys. Consumers continue to receive responses from cache, and the cache is technically refreshed each request, but the underlying data hasn't been updated in days. The fix is explicit monitoring of revalidation success rates and explicit alerting when the gap between cache age and origin write age exceeds the staleness budget.

Failure mode 4: hot-key concentration. A small number of agents account for the vast majority of read traffic — typically because they are featured in marketplace listings, recommended by routing systems, or queried by analytics dashboards. Edge cache hit rates look great in aggregate because the hot keys are always warm, but tail-key reads (agents with low query volume) consistently miss cache and pay the full origin cost. The fix is acknowledging that tail-key reads will be slower than head-key reads and either accepting that, or pre-warming the regional cache for the long tail at the cost of additional storage.

Failure mode 5: dispute lag. The oracle's dispute path is fast but the dispute count field is cached for minutes. A new dispute is filed, but consumers continue to route work to the disputed agent because their reads return the pre-filing dispute count. The fix is making the dispute count one of the realtime-tier fields with sub-5-second staleness budgets and explicit invalidation events when new disputes are filed.

Failure mode 6: score lag turning into incident lag. The oracle's anomaly detection correctly identifies a >200-point score swing within minutes of the underlying evidence landing. The cache layers serve the pre-anomaly score for the duration of the staleness budget. Consumers continue routing to the agent for several minutes after the anomaly has been recorded internally. The fix is treating anomaly events as cache-invalidation events, not just score-update events; when an anomaly fires, the affected agent's cached responses are explicitly purged across all layers regardless of TTL.

None of these failure modes are exotic. They are the standard failure modes of any high-throughput cached read system, and the solutions are well-understood. The problem is that trust-oracle teams routinely treat the read path as engineering they can do later, after the more interesting scoring work is done. The cost of that decision is that the read path's failure modes show up in production, not in design review.

Batching, fan-out, and the protocol-level optimizations that compound

A mature trust oracle exposes more than a single-agent read endpoint, because the consumers worth designing for almost never want to look up exactly one agent at a time. The protocol-level optimizations that matter most fall into three categories.

Bulk read endpoints. A single API call that accepts a list of agent identifiers and returns a list of records, with the cache layer free to satisfy each record from whichever tier holds it warm. The performance gain over N individual calls is substantial: one TLS handshake, one HTTP round trip, one parse of the response envelope, regardless of how many agents are in the batch. A consumer rendering a marketplace search results page with 50 agent badges should be able to fetch all 50 trust records in a single request whose latency is barely worse than fetching one. Without bulk reads, the consumer either pays N times the per-request overhead or builds its own batching layer in front of the oracle, both of which leak performance and correctness in subtle ways.

Subscription-style updates. For consumers that care about ongoing changes — orchestration platforms watching their pool of agents, dashboards displaying live trust feeds, risk systems flagging certification tier transitions — the right primitive is not repeated polling but server-pushed updates over a long-lived connection. The consumer subscribes to a set of agent identifiers and receives a notification whenever any of their scores changes meaningfully (with "meaningfully" itself being a parameter the consumer can tune). The server-side cost of a subscription is far lower than the cost of serving the equivalent volume of polling reads, and the consumer-side timeliness is much better. The catch is that subscription delivery has its own correctness properties to manage — guaranteed at-least-once delivery, ordering guarantees within an agent's update stream, replay capability for consumers that briefly disconnect — and most oracles ship subscriptions only after they have been pressured by consumers tired of polling.

Field-projection requests. A read request that specifies which fields the consumer actually needs, returning only those fields and skipping the rest. A routing system that only cares about composite, tier, and dispute count should not be paying the latency and bandwidth cost of receiving the full dimension breakdown, evidence links, and history. Field projection lets the cache layer satisfy each request from the layer that holds the requested fields most efficiently — the fast composite-and-tier path stays in edge cache; richer reads fall through. The consumer-side win is in latency and bandwidth; the oracle-side win is in cache hit rates, because the most common projections benefit from very high locality.

None of these optimizations is exotic. They are standard primitives in any mature read-heavy API. The reason they are worth flagging in a trust-oracle context is that the consumer mix is dominated by exactly the patterns these optimizations help: bulk lookups during search, subscriptions during routing, projection during high-frequency dashboard rendering. An oracle that lacks them imposes substantial implementation cost on every consumer to recreate the missing primitive in client code, and that cost is paid in correctness failures more often than in raw latency.

Observability: what to measure on the read path

A trust oracle that does not measure its own read path cannot improve it and cannot prove its SLA. The measurement discipline is similar to any other high-throughput service, with a few specific dimensions that matter more for trust use cases than for general-purpose APIs.

Latency distributions per layer, per field, per region. Aggregate p50/p95/p99 across all reads is too coarse to be useful. The right cuts are by cache layer (so that cache miss rates show up as latency degradation in a specific layer rather than as a vague aggregate spike), by field (so that a slow dimension breakdown does not get lost in a fast composite-only mix), and by region (so that a single misbehaving POP shows up as a regional anomaly rather than a global degradation).

Cache hit rates per layer, per key class. Edge cache hit rate aggregated across all reads is again too coarse. The right cuts are by key class (head versus tail agents, popular versus niche) and by request type (full record versus projected fields). A head-key hit rate above 95% is healthy; a tail-key hit rate above 50% is unrealistic; a projected-field hit rate above 90% is the right target. Tracking each of these as a separate metric makes the cache health legible.

Freshness gap distributions. For each field with a published staleness budget, the actual age of served responses should be measured and compared to the budget. The healthy distribution looks like the actual age is well below the budget for almost all reads, with rare excursions toward the budget that trigger investigation. A distribution where actual ages cluster near the budget ceiling is a signal that the cache pipeline is working but stretched, and capacity is about to become a problem.

Subscription delivery latency and reorder rates. For oracles that ship subscriptions, the time from a write landing at origin to the consumer receiving the notification is the relevant metric. Aggregate delivery latency, p99 delivery latency, and the rate of out-of-order deliveries within a single agent's stream all need to be tracked. Subscription quality degrades silently if not measured; consumers will continue to receive notifications, but the notifications will be late or out of order in ways that produce incorrect downstream behavior.

Bypass usage rates. The fraction of reads that explicitly bypass the cache layer to hit origin is itself a useful metric. A bypass rate that creeps up over time is a signal that consumers are losing trust in the cached path — typically because freshness manifests are showing higher actual ages than they expect, or because cached responses are producing incorrect downstream decisions. Investigating bypass rate increases catches read-path degradation early, before the consumers stop using the oracle entirely.

The reader artifact: the Oracle Read SLA Spec template

When a buyer, platform, or regulator integrates against a trust oracle, they should write down what they actually need from the read path before they begin integration. Most teams skip this step, integrate against whatever the oracle ships, and then discover six months later that the read path does not support their use case. The SLA Spec is a one-page artifact that prevents that.

Section A: Volume

• Expected reads per second at baseline: ___
• Expected reads per second at peak: ___
• Expected ratio of head-key reads (top 1% of agents) to tail-key reads: ___
• Expected per-request fan-out (lookups per consumer-facing transaction): ___

Section B: Latency

• Required p50 read latency: ___ ms
• Required p99 read latency: ___ ms
• Maximum tolerable p99 during oracle incidents: ___ ms
• Behavior when latency budget is exceeded: fail open / fail closed / cached fallback / explicit error

Section C: Staleness

• Acceptable composite score staleness: ___ s
• Acceptable certification tier staleness: ___ s
• Acceptable dispute count staleness: ___ s
• Acceptable bond posture staleness: ___ s
• Acceptable evaluation history staleness: ___ s
• Acceptable trajectory data staleness: ___ s

Section D: Freshness signaling

• Required: freshness manifest in every response (recommended yes for production)
• Required: signed freshness in cryptographic responses (recommended yes for high-stakes use)
• Required: explicit cache-bypass endpoint for transactional reads (recommended yes for any consumer that gates value transfer on the score)

Section E: Failure semantics

• Behavior when oracle is unreachable: fail open / fail closed / use last known good / explicit error to caller
• Maximum acceptable last-known-good age before fallback degrades to fail-closed: ___ minutes
• Notification path when fallback engages: ___
• Recovery procedure when oracle returns: ___

Section F: Audit

• Required: log every oracle read for compliance (recommended yes for regulated industries)
• Required: replay evidence on demand from origin (recommended yes for any use case where decisions might need legal reconstruction)
• Required: time-travel reads — query the score as of a past timestamp (required for incident reconstruction)

Walking through this spec with the oracle's operators surfaces the integration risks before code is written. An oracle that cannot meet the latency requirements forces the consumer to either accept slower transactions or skip oracle reads on hot paths. An oracle that does not support time-travel reads cannot serve regulated consumers who need to reconstruct historical decisions. An oracle that does not expose freshness manifests forces the consumer to treat every response as either fresh or unverifiable, with no middle ground. None of these are deal-breakers in themselves, but they should be deal-shapers for the integration architecture.

The economic case for taking read latency seriously

There is a temptation, especially in early-stage oracle projects, to treat read latency as a polish item — something to optimize after product-market fit. This is the wrong instinct because the read path's quality compounds with usage in ways that are hard to recover from once usage materializes.

A fast oracle gets called more often. Being called more often produces more telemetry about which agents are being looked at, which scores influence which decisions, which dimensions consumers actually care about. That telemetry is itself a strategic asset; it tells the oracle operator where to invest in improving the score and which fields deserve more sophisticated read-path engineering. A slow oracle gets called less often, produces less telemetry, and ends up improving more slowly than its faster competitors. The compounding goes in both directions, and the gap between a fast oracle and a slow one widens over quarters.

A fast oracle also unlocks consumer use cases that a slow oracle cannot serve. Real-time routing, in-the-loop trust gating, dashboard widgets, A2A handshakes, marketplace search ranking — none of these are feasible against a 1-second read path. They are all feasible against a 50ms read path. The difference between feasible and infeasible determines the surface area of the agent economy that the oracle can underpin. A slow oracle is, at best, a compliance archive. A fast oracle is the substrate underneath agent decisions.

The economic case generalizes. Infrastructure that wants to be infrastructure has to be cheap enough at read time that consumers do not have to think about whether to use it. DNS is cheap to query. HTTPS is cheap to verify. The certificate transparency log is cheap to consult. Their universal use depends on that property. A trust oracle that wants the same gravitational pull has to meet the same bar.

Counter-argument: "Strong correctness matters more than read latency"

The strongest objection to investing heavily in read-path engineering is that the score's correctness is the product, and that consumers who want correctness should accept the latency cost. The objection has two flavors. The first is technical: caching introduces consistency complications, every layer of cache is a layer of potential staleness, and serious trust decisions deserve to read from the canonical store. The second is moral: optimizing for speed encourages consumers to read more often than they should, and the right behavior is to read carefully, not abundantly.

The technical version is partially right and largely a misframing of the tradeoff. Caching does introduce staleness, but per-field staleness budgets and explicit freshness manifests turn that staleness from a liability into a property the consumer can reason about. The canonical store is not magically more correct than a cache that was populated from the canonical store moments ago and is operating well within its staleness budget; it is more recent in a way that may or may not matter for the consumer's use case. Forcing every consumer to pay origin latency for every read is not a correctness win; it is a refusal to think carefully about which reads actually need origin freshness and which do not.

The moral version is more interesting but does not survive contact with the actual usage pattern of trust oracles. The consumers reading the oracle most often are not making sloppy decisions about whether to consult it; they are automated systems making thousands of small decisions per minute, each of which benefits from having the trust signal available. Encouraging them to read less means encouraging them to make trust-blind decisions for the marginal cases — which is exactly the failure mode trust infrastructure was built to prevent. The high-touch human procurement decision is not the use case being optimized for. It is the orchestration platform routing tickets, the marketplace ranking listings, the A2A handshake before a settlement that benefits from cheap reads. The right design philosophy is to make trust reads so cheap that no consumer ever has to choose between speed and trust-awareness.

There is a smaller version of the objection that does survive: it is true that very-high-stakes reads should bypass the cache and go to origin even when slow. The Oracle Read SLA Spec acknowledges this explicitly. The architecture is not "cache everything"; it is "cache the reads that benefit from caching, and provide a clean bypass for the reads that do not." Those are compatible goals when the read path is engineered with both in mind from the start.

What Armalo does

Armalo's Trust Oracle at /api/v1/trust/ is engineered as a tiered read path. Edge nodes serve the most common queries — composite score, certification tier, dispute count — under 80 milliseconds at the 99th percentile. Regional caches serve richer responses including dimension breakdowns and recent evaluation summaries with single-digit-second freshness budgets per field. The origin handles writes, anomaly detection, dispute adjudication, and time-travel reads for audit consumers. Every response includes a freshness manifest specifying the actual age of each field; signed responses commit to those ages so that replay attacks become detectable. Cache invalidation is field-aware — a new dispute does not bust the entire response, only the dispute count. Anomaly events trigger explicit cross-layer purges so that a flagged agent's cached scores do not continue to drive routing decisions while the investigation runs. The dispute count and active anomaly fields are realtime; the composite score and tier are 60-second and 5-minute respectively; bond and history fields run on minute-and-hour budgets. Consumers who need stricter freshness can use the explicit bypass endpoint and pay the latency cost knowingly. The point is not that this is the only valid architecture. The point is that an oracle without explicit per-field staleness budgets, a freshness manifest, and a cache-bypass path is an oracle that cannot be safely integrated into systems that make automated trust-aware decisions at scale.

FAQ

Why per-field staleness rather than per-response? Because different fields have radically different change rates and consumer sensitivities. Composite scores move slowly; dispute counts must be realtime; tier transitions are rare. Forcing all of them onto the same staleness budget either makes the cache useless (if budgets are short) or makes high-sensitivity fields dangerously stale (if budgets are long). Per-field budgets pick the right tradeoff for each piece of information.

Does cache invalidation get complicated when fields have different budgets? Yes, and the complexity is justified. The alternative — coarse-grained invalidation that busts the whole response on any change — destroys cache hit rates. Field-aware invalidation requires more engineering investment up front and pays back many times over in steady-state cache performance.

What happens if the freshness manifest disagrees with reality? That is itself a detectable failure. Consumers should track the gap between the manifest's claimed freshness and the timestamp of the underlying writes they receive notification about. Persistent gaps indicate bugs in the cache invalidation pipeline. The fix is monitoring, not pretending the failure mode does not exist.

What is the right p99 latency target for a production oracle? For the fast subset (composite, tier, dispute count): under 100ms is the bar at which the oracle is feasible inside hot loops. For the rich subset (with dimension breakdowns and evaluation summaries): under 250ms is reasonable. For origin reads (full record, time-travel, audit): seconds are acceptable because these are not high-frequency reads.

How do consumers handle oracle outages? With an explicit fallback policy declared up front in the Oracle Read SLA Spec. The choices are fail open (proceed without trust check, log the omission), fail closed (refuse the transaction), use last-known-good (proceed with stale data up to a defined age limit), or explicit error to caller (let the calling system decide). Each is appropriate for different stakes; what is not appropriate is leaving the behavior undefined and discovering it during the first oracle outage.

Can the read path be built on a public blockchain? Direct on-chain reads do not satisfy the latency or throughput requirements at scale. The right architecture is anchoring cryptographic commitments on-chain — proving the integrity of the off-chain read path — while serving the actual reads from the tiered cache hierarchy. Consumers can verify the on-chain commitments on demand without paying on-chain costs for every read.

What about regulatory consumers who need historical reads? Time-travel reads against origin are the right path. They are slower (typically hundreds of milliseconds to low seconds) because they have to reconstruct state at a specific past moment, but they are also extremely low frequency — regulators do not need real-time access to historical scores. Treating audit reads as a separate class with their own SLA solves the problem cleanly.

How do consumers know whether a response was served from cache or origin? The freshness manifest specifies this. A signed response includes the layer that produced each field and the age of that field at response time. Consumers can use this both for operational monitoring and for cryptographic verification.

Bottom line

A trust oracle's read path is not a polish item. It is the property that determines whether the oracle becomes infrastructure or becomes a slow query nobody runs. Cache hierarchies exist for exactly this kind of asymmetric workload. Per-field staleness budgets exist because different fields have different consumer sensitivities. Freshness manifests exist because consumers need to know what they read. The Oracle Read SLA Spec exists because integrating against an oracle without writing down what you need from it is the most reliable way to discover, six months in, that you needed something the oracle does not support. Trust is read constantly. Engineer accordingly.