corpus — may we contact this person?

Corpus is the answer to one question, asked before anything is done to a human being: may we contact this person, on this channel, right now? Behind it sit the people themselves — the identifiers that point at them, the consents somebody gave, the suppressions somebody asked for, and the merges that decided two records were one person.

Health — live

not asked

This check runs in your browser and has not run yet. With JavaScript off it never runs, and this line stays as it is — which is the honest answer: nothing was asked, so nothing is known.

This route is open to anybody and carries no Access-Control-Allow-Origin header, so a browser on this origin normally cannot read the answer even though the request succeeds. That is deliberate — the route exists for the deploy's health-checked auto-revert and for monitoring — and it is why the badge above usually says answered, unreadable here rather than up. The curl below is not bound by the same-origin policy and shows what it actually returns.

Verify it yourself — recorded 2026-09-06

$ curl -s https://corpus.lrs.amtechhq.com/api/corpus/health
{"service":"corpus","status":"ok"}

$ curl -s https://corpus.lrs.amtechhq.com/api/v1/consents/summary
{"success":false,"errors":["an Authorization: Bearer <api_key> header is required"],
 "meta":{"timestamp":"2026-09-06T18:06:13Z"}}
# HTTP 401

Nothing about a person is on this page, and nothing ever will be. Not a count, not a summary, not an anonymised sample. Every read in corpus is behind the service credential, and a public demonstration page inventing "1,600,000 people" or "42 suppressions today" would be inventing facts about real human beings. The refusal above is the whole of what this service will tell a stranger, and that is the correct amount.

The two decisions that bind hardest here

Absence is not evidence

A query that finds no suppression must never be indistinguishable from a query that could not run. A failed lookup and a clean record produce the same empty result set, and if the code treats them the same it will contact somebody who asked not to be contacted and the logs will show nothing wrong. This is why the platform is full of explicit third states — unscored in fraud is the same idea, and it is never rendered as clear and never counted as one.

Consent must be provable

The second reading of the same principle, and the one that was wrong in shipped code: a query that found no suppression must never be mistaken for proof of permission. Not having been told no is not the same as having been told yes. That decision has a business cost attached and it was made anyway.

What corpus does — from source: the route table

Route	What it is for
POST /api/v1/persons/intake	The immutable record of what arrived, written before any matching happens.
POST /api/v1/persons/resolve	Given identifiers, decide which person this is.
GET /api/v1/persons/{key}/may-contact	The question above. The one with legal consequences if it answers wrong.
POST /api/v1/suppressions	Somebody asked not to be contacted.
GET /api/v1/identifiers/suppression	Is this phone or email suppressed?
POST /api/v1/domain-consents	Consent recorded at the level of a domain, with review and supersede steps.
GET /api/v1/person-merge-candidates	Two records that might be one person — a decision, and a reversal path for when it was wrong.

Every one of them requires the service credential. There is no public boundary in corpus at all, which is the correct number of public boundaries for a service that holds people.