Fakes estate

calab-mocks stands in for external systems so local development, smoke tests, and demos do not call the real ones. It is its own deployable estate, separate from NeuralOps. A consumer of these fakes exists in calab-ai/neuralops-accelerator. That repo creates the connection wiring. How the consumer is wired must not shape the fake: the fake speaks the external system's protocol.

Read Start here from top to bottom. Search covers the rest of docs/.

Personality. One external HTTP API, packaged as a module on the shared FastAPI fake host. The host is the same for every personality (health, fixture loading, and a credential pair). QDox uses that pair as HTTP Basic. ServiceNow uses it as OAuth client credentials.

Fixture. The sample corpus a personality serves: JSON metadata plus binaries such as PDFs, in a fixtures/ folder next to that personality. The fake returns those files. It does not generate them on the fly.

Separate deploy. This estate deploys on its own, into the mocks application landing zone, with azd. It is not part of the NeuralOps deploy. Do not create those resource groups here, and do not azd down them.

Start here

If you need Read
How this site is built, and how to preview it site/docs-site.md
Sign-in on the published site entra-auth.md
Deploy this estate on Azure, separate from NeuralOps azure-deployment.md
The QDox personality: routes, local run, adding another fake-host/README.md
The ServiceNow personality: Table API, OAuth, connector base_url fake-host/README.md
Where QDox fixtures live fake-host/app/personalities/qdox/fixtures/
The SAIR SQL contract (tables, views, when they are applied) projects/sair/edw-schema.md
How to file work linear-work-items.md
What the triage labels mean triage-labels.md

How a fake comes into existence

A new external system needs a fake that speaks that system's protocol. The fake's data lives in this repo. The product's pointer at the fake lives in the consumer repo.

flowchart LR
  need(("New external system needs a fake"))
  proto["Protocol the fake must speak<br/>HTTP, TDS/ODBC, or another later"]
  mocks["calab-mocks seeds the fake<br/>personality or database, plus the git corpus"]
  consumer["neuralops-accelerator holds the connection config<br/>that wiring is not created here"]
  reset(("Operator applies the consumer config"))
  run(("A business run hits the fake"))
  need --> proto --> mocks --> consumer --> reset --> run

What this repo provisions

Landing-zone resource groups already exist. An operator azd up fills them, and so does a push to main that changes estate paths (infra/**, azure.yaml, sql-estate/**, .github/workflows/azure-estate.yml, fake-host/**). A docs-only push does not provision or seed. The consumer config is published from neuralops-accelerator, not from this repo.

flowchart TB
  lz["Landing zone resource groups<br/>rg-mock-all-aue-core<br/>Container Apps environment, registry, Key Vault, SQL"]
  cd(("Estate-path push to main,<br/>or operator azd up"))
  aca["QDox Container App<br/>ca-qdox-mock-all-aue-01<br/>FAKE_HOST_PERSONALITIES=qdox<br/>Basic credentials from Key Vault"]
  sql["Azure SQL database edw<br/>sql-mock-all-aue-01<br/>Entra and SQL auth, seeded from git<br/>7 SAIR views"]
  host["fake-host FastAPI app<br/>fails closed if credentials are unset<br/>GET /health is unauthenticated"]
  qdox["qdox personality<br/>Basic auth on every route<br/>catalogue.json plus binary fixtures"]
  lz --> cd
  cd --> aca
  cd --> sql
  aca --> host --> qdox

What a consumer calls

The fake is already up. The consumer calls it over the same protocols the real systems use.

flowchart TB
  run(("SAIR run, or an admin connection test"))
  http["HTTP Basic GET /Record<br/>then the catalogued file"]
  tds["TDS query against dbo.vw_*"]
  aca["QDox Container App"]
  sql["Azure SQL database edw"]
  run --> http --> aca
  run --> tds --> sql

Agent docs

Conventions for agents working in this repo: