Docs / Status checks

Status checks

Four small checks from customer view to release gate.

A green process is not a green Brain. Check the customer path in four small layers.

Customer view#

Open the Project Console. Enter the API base, Brain ID, and project key.

The console is read-only. It first proves the key can read that Brain, then settles identity, Records and sources, derived Memories, and recent recall independently. A slow corpus census cannot hold the other reads hostage. Nothing is stored in a cookie, URL, localStorage, or sessionStorage.

Green means: the Brain exists under that project credential and each existing read operation returns its own state.

It does not mean: a new write becomes retrievable, idempotency holds, citations resolve, or data survives a restart.

Integration path#

Run the doctor against the same URL, key, and Brain your application uses:

.venv/bin/python scripts/brain_doctor.py \
  --base "$BRAIN_API_BASE" \
  --key "$BRAIN_API_KEY" \
  --brain "$BRAIN_ID"

The doctor walks the customer path rather than pinging a health route. It writes labelled, idempotent probes, checks read-your-writes, asks for cited Context, follows evidence, and verifies the stable error shape.

Green means: the integration path it just exercised worked end to end.

Important: the doctor writes small probe Records. Use the read-only Project Console when writes are not appropriate.

Deployment identity#

Confirm the serving revision, traffic, image, and store mode:

gcloud run services describe "$SERVICE" \
  --project "$GCP_PROJECT" \
  --region "$GCP_REGION" \
  --format='yaml(status.url,status.latestReadyRevisionName,status.traffic,spec.template.spec.containers[0].image,spec.template.spec.containers[0].env)'

For the public sandbox, BRAIN_STORE must be inmemory. A real customer spine must be private, allowlisted, durable, restart-tested, and isolated before onboarding. Never infer the store from a successful HTTP response.

Release gates#

Run the smallest deterministic release board:

.venv/bin/python scripts/check_api_simplicity.py
.venv/bin/python scripts/check_error_docs.py
.venv/bin/python scripts/check_quickstart.py
.venv/bin/python scripts/build_docs_site.py
git diff --exit-code -- docs/site

For retrieval or answer changes, also run the binding evaluation gate described in docs/EVAL_GATING_POLICY.md. For a customer deployment, finish with brain_doctor.py against the actual customer URL and credential.

Green means: the contract stayed small, raised errors stayed documented, every documented curl returned its claimed status, and committed site bytes match the deterministic builder.

Yellow still matters: contract-fuzzer warnings, database-dependent skips, public InMemoryStore behavior, and any current limitation remain yellow even when these commands exit zero.

# Status checks

A green process is not a green Brain. Check the customer path in four small layers.

## Customer view

Open the [Project Console](dashboard.html). Enter the API base, Brain ID, and project key.

The console is read-only. It first proves the key can read that Brain, then settles identity,
Records and sources, derived Memories, and recent recall independently. A slow corpus census cannot
hold the other reads hostage. Nothing is stored in a cookie, URL, `localStorage`, or
`sessionStorage`.

**Green means:** the Brain exists under that project credential and each existing read operation
returns its own state.

**It does not mean:** a new write becomes retrievable, idempotency holds, citations resolve, or
data survives a restart.

## Integration path

Run the doctor against the same URL, key, and Brain your application uses:

```bash
.venv/bin/python scripts/brain_doctor.py \
  --base "$BRAIN_API_BASE" \
  --key "$BRAIN_API_KEY" \
  --brain "$BRAIN_ID"
```

The doctor walks the customer path rather than pinging a health route. It writes labelled,
idempotent probes, checks read-your-writes, asks for cited Context, follows evidence, and verifies
the stable error shape.

**Green means:** the integration path it just exercised worked end to end.

**Important:** the doctor writes small probe Records. Use the read-only Project Console when writes
are not appropriate.

## Deployment identity

Confirm the serving revision, traffic, image, and store mode:

```bash
gcloud run services describe "$SERVICE" \
  --project "$GCP_PROJECT" \
  --region "$GCP_REGION" \
  --format='yaml(status.url,status.latestReadyRevisionName,status.traffic,spec.template.spec.containers[0].image,spec.template.spec.containers[0].env)'
```

For the public sandbox, `BRAIN_STORE` must be `inmemory`. A real customer spine must be private,
allowlisted, durable, restart-tested, and isolated before onboarding. Never infer the store from a
successful HTTP response.

## Release gates

Run the smallest deterministic release board:

```bash
.venv/bin/python scripts/check_api_simplicity.py
.venv/bin/python scripts/check_error_docs.py
.venv/bin/python scripts/check_quickstart.py
.venv/bin/python scripts/build_docs_site.py
git diff --exit-code -- docs/site
```

For retrieval or answer changes, also run the binding evaluation gate described in
`docs/EVAL_GATING_POLICY.md`. For a customer deployment, finish with `brain_doctor.py` against the
actual customer URL and credential.

**Green means:** the contract stayed small, raised errors stayed documented, every documented curl
returned its claimed status, and committed site bytes match the deterministic builder.

**Yellow still matters:** contract-fuzzer warnings, database-dependent skips, public
`InMemoryStore` behavior, and any current limitation remain yellow even when these commands exit
zero.