Google Antigravity

Status — what a conformance test found

served & verified

answers with real universe data, and this build checked that response against the vendor's spec.

deviation

served and faithful to the real provider, but failing the vendored spec — usually a bug in the spec.

retired

the vendor removed the endpoint; snapshots pinned before that date still serve it.

planned / deferred

not served yet — an explicit coverage error naming the gap, never invented data.

excluded

out of the claim by policy (writes, and surfaces we refuse); not in any denominator on this page.

Mode — what kind of answer a row gets

derive

the response is computed from artifact rows that already exist

generate

canon does not carry this yet; the generator will produce it, then derive

empty

the true answer for this universe is an empty collection — reason + reviewed date required

refuse

mirror the provider's OWN refusal (e.g. its 403 for a non-admin token) — reason + reviewed date required

read-only

a write named in the manifest because clients probe it; the read-only 403 IS its final response, and it never joins the badge denominator

scratch

a write this replica ACCEPTS, into a per-key 24-hour overlay, answering with the provider's own success shape - reason + reviewed date required. The compiled artifact is unchanged and no other caller ever sees the row; a caller WITHOUT a scratch-enabled key gets the read-only refusal on the identical path. Like read-only it never joins the badge denominator (founder ruling 5, 2026-09-17: the published figure has meant READ operations served since A0.1), and unlike read-only it ANSWERS, so the generation report counts it in its own `scratch` column rather than in (excluded). Scratch never creates a pull request, a branch, a commit or a diff - those are canon structure the overlay cannot invent

A row with no mode shown has not been judged yet. Modes are the manifest's own words, from coverage/MODES.yaml; every empty and refuse carries a written reason and a review date before it counts as final.

Held — buildable, deliberately not built yet

data-licensing

the values are VENDOR reference data this project holds no grant to redistribute. Serving needs an independently licensed source, so the outstanding work is a licensing answer, not code.

held is a label, not a mode and not a status. A held row is one somebody looked at, judged buildable, and left with the blocker named — so it is not covered, counts against the ratio above exactly like any other unbuilt row, and still answers the coverage 404. It buys nothing; it only tells you why.

Badge — where Deep starts

Full

every published read row has a final answer

Deep

60% up to 100%

Partial

25% up to 60%

Preview

under 25%

REST + GraphQL + git rows that are not `excluded`. Write operations are NOT rows (DECISIONS 2026-09-01 decision 9): they are counted in meta.write_operations and never enter this ratio.