Attribute the served read floor (~0.2 s server-side on a trivial read) and expose it as usage

[ragnorc]

Measurement

Call	Wall time, 3 runs
GET /healthz (round trip only)	0.10 s, 0.11 s, 0.18 s
omnigraph snapshot --json (metadata only)	0.66 s, 0.58 s, 0.57 s
query -e 'match { $p: Person } return { $p.slug } limit 1'	0.36 s, 0.34 s, 0.36 s
query -e 'match { $p: Person } return { count($p) as n }' (4,678 rows)	0.45 s, 0.35 s, 0.35 s
keyed lookup Person { slug: $s }	0.42 s, 0.39 s, 0.38 s
omnigraph version (CLI startup)	0.01 s

So a trivial served read costs about 0.35 s, of which 0.10–0.15 s is the round trip. The remaining ~0.2 s is server-side and unattributed. It is not manifest reloading: the warm-read contract (crates/omnigraph/tests/warm_read_cost.rs, since v0.7.1 #268) makes a warm same-branch read zero __manifest reads and one version probe. snapshot being slower than a query is itself unexplained.

For the agent workload (many small calls per task) this fixed floor outranks any plan choice; RFC 0047 (#791) makes this rollout step 7.

Ask

1. Attribute the floor per phase on the server: auth/token verification, settings resolution, version probe (object-store round trips and their latency from the serving region), compile-cache hit, table open by location+version, the scan itself, result encoding. The existing helpers::cost object-store counters and warm_read_cost.rs give the request counts; wall time per phase needs a tracing span or the additive usage object RFC 0047 (rfc: RFC 0047, search plan truth on engine v2 #791) proposes, which reports time per phase (authentication, target resolution, compilation, planning, execution, serialization).
2. Explain why snapshot costs ~0.6 s when a query costs ~0.35 s.
3. Cut what the attribution shows, in order of size. Caching of immutable version-pinned state is invariant-12-clean if that is where the time is; a second version probe or a per-request policy/token round trip would be a different fix.

Acceptance

A trivial served read's server-side time is reported per phase in the response (or a tracing export), and a cost test pins the object-store request count of that read at its current value so the floor cannot regress silently.

[ragnorc]

Attributed on main (80406fee) against a local RustFS, with and without toxiproxy adding 15 ms each way (~30 ms per request). The fixture is a 4,678-row Person graph, served with omnigraph-server --cluster s3://…. Times are medians of 7.

Call	RustFS ~1 ms	+30 ms per request
GET /healthz	12 ms	15 ms
trivial read (limit 1)	20 ms	257 ms
count	20 ms	260 ms
keyed lookup	20 ms	293 ms
snapshot	21 ms	495 ms

With fast storage the server-side floor is about 8 ms, so the floor is serial object-store round trips, not CPU.

Requests per warm call. I put a logging TCP proxy in front of RustFS; three runs per call were identical.

• Trivial read, 8 requests:
  • GET _schema.pg
  • HEAD and GET _schema.ir.json
  • HEAD and GET __schema_state.json
  • LIST __manifest/_versions/
  • 2 data-file range GETs
• Keyed lookup, 9 or 10: the same prefix plus more data GETs.
• snapshot, 14: the schema check and the _versions/ LIST twice, then one more LIST and a GET of the manifest. That explains why snapshot costs about twice a query (question 2).

Where the unattributed time goes. The 5 schema requests (about 3 serial round trips) come from ensure_schema_state_valid, which re-validates the full schema contract on every operation so a long-lived handle catches external drift of the source, IR or state (see its comment in crates/omnigraph/src/db/omnigraph.rs). The warm-read contract in warm_read_cost.rs pins __manifest reads, so these schema-file reads are outside what it guards. At S3 latency they cost more than the manifest probe itself. Separately, the limit 1 read plans a full-fragment range (4,678 rows) rather than a single row.

A cheap direction consistent with invariant 12: a conditional check (ETag or If-None-Match) of the three contract objects in one parallel round trip, or folding a contract digest into the manifest the version probe already reads. Either would keep drift detection without two sequential round trips per request.