Coverage

"Is this organisation covered for this repository?" — one question, eight possible answers, computed by a pure, versioned function over published documents only.

The eight answers

This enumeration is frozen. Answers are additive-only: a future version may explain more, never rename these.

The complete coverage answer set, in precedence order

Answer	Meaning
`yes-via-pass`	An active Pass covers every registered repository, including this one.
`yes-via-project`	An active Project entitlement whose scope contains this repository.
`yes-via-portfolio`	An active Portfolio entitlement whose scope is the organisation that owns this repository.
`yes-via-waiver`	The repository granted this organisation a gratis, public waiver. Waivers are checked before any entitlement short-circuit, so a waived organisation is reachable even with no account and no verified domain.
`yes-via-donation`	An active Donation Entitlement covering this scope.
`lapsed-in-grace`	The term ended but the 30-day grace window has not. Carries the period end and the grace end so a late invoice is visibly not a violation yet.
`no-entitlement-required-under-threshold`	The organisation self-certified as below the threshold and that certification has not expired. Carries the certification date.
`no`	No current entitlement, no waiver, no valid threshold certification. Absence of a record answers "no" — never an error, so a scanner can read it.

How the answer is computed

Only published documents are inputs. The company's signed entitlement record, the repository record, and the public waiver list. No database is consulted, which is why the endpoint cannot be made slow or expensive by traffic.
Time is a parameter, not a clock read. The function is deterministic: the same inputs and the same instant always produce the same answer, and the answer echoes the instant it used so you can re-derive it.
Grace and lapse are derived from dates, never published as statuses. A published status of active plus an expired period is exactly what lapsed-in-grace is computed from.
A suspended entitlement answers no immediately — a chargeback is not a grace period.
A repository that is not registered is an error, not an answer (repo_not_registered). A repository that quit or was delisted still computes: entitlements and vesting stand regardless of what the repository did.

The walkthrough, on one lookup

Question: is the organisation at alpenglow-systems.example covered for sample-collective/atlas-forms? Four documents answer it, in this order, and nothing else is consulted:

Resolve the organisation. Look alpenglow-systems.example up in /entitlements/domain-index.json → co_01j9smpvrgh7m3q2w8n5xb4tc0. A domain that is absent resolves to nothing, and the answer is no — an absent record is an answer, never an error.
Check the waiver list first. Read /waivers/R_kgDOSMPL0007.json. A live waiver naming this organisation answers yes-via-waiver and stops, before any entitlement is looked at — which is what makes a waived organisation with no account and no verified domain reachable at all. A waiver still inside its cooling window counts: cooling changes vesting, never the coverage answer.
Read the signed entitlement record. Fetch /entitlements/co_01j9smpvrgh7m3q2w8n5xb4tc0.jws, verify its ES256 signature against /jwks.json, and walk its entitlements: a Pass covers every registered repository; a Project entitlement covers the repositories named in its scope; a Portfolio entitlement covers the repositories owned by the organisation in its scope; a Donation Entitlement covers its recorded scope.
Apply the dates, not the label. Published status is only active, suspended or void. Grace and lapse are computed: now inside the period ⇒ covered; past the period but inside the 30-day grace ⇒ lapsed-in-grace; past the grace ⇒ no; suspended ⇒ no immediately. A valid, unexpired threshold self-certification and no entitlement ⇒ no-entitlement-required-under-threshold.

Every input is a document you can fetch and check yourself, which is the point: the answer is not a database query anyone has to trust, it is a function you can rerun.

The domain index, as published

Domain-verified organisations are indexed by domain so a scanner can resolve a company without knowing its identifier. The index is a published artifact: /entitlements/domain-index.json. It carries domains and identifiers and nothing else — no names, no contacts, no amounts.

Sample domain index — 6 verified domain(s), generated at 2026-09-03T16:17:53Z

Verified domain	Company identifier
`alpenglow-systems.example`	`co_01j9smpvrgh7m3q2w8n5xb4tc0`
`bergwerk-logistics.example`	`co_01j9smpw4kd2f6t9r0h3z7ycva`
`meridian-freight.example`	`co_01j9smq1ex7n0q4b6d9s2h5tvj`
`oakhaven-utilities.example`	`co_01j9smpz6th1j4x7v0p3d5wqfe`
`tessellate-cloud.example`	`co_01j9smpy2rf8h5w1t3m6c9xkbn`
`tessellate.example`	`co_01j9smpy2rf8h5w1t3m6c9xkbn`

Verified-domain → company id index for the coverage function (FS10-024). Domain-verified organisations only; a domain absent here answers `no`.

Organisations that verified by officer attestation rather than by domain are deliberately absent from this index — there is no domain to key them by. They are resolved by identifier, and a lookup by name is a POST, never a query string.

Organisation names never go in a URL

When the endpoint activates, a lookup by domain will be a POST. Only opaque company identifiers are accepted in a GET query string, because a GET carrying a third party's name would land that name in shareable links, proxy logs, and shared caches. The same rule governs every form on this site.

The source is published

The function and its test vectors publish in the specification repository, and the deployed bundle's module hash is checked against that published copy in continuous integration. If the two disagree, the deploy fails. See algorithms and schedule versions.