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/.
Words you need before the links
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: