Buddora

The operating system for animal health, services, safety, commerce, education & identity.

This site is a public summary of Buddora's engineering: architecture, APIs, data & event models, security, operations, and deployment.

It is not the canonical record. The canonical documents live in the repository under docs/ — docs/architecture/DEPLOYMENT.md for what is actually deployed, docs/operations/DEPLOYMENT.md for how to deploy it, docs/adr/ for decisions, docs/security/ for the security analysis, and ROADMAP.md for scope and status. Where this site and those documents disagree, they are right. This page exists because this site drifted badly by pretending otherwise.

Current implementation status

Buddora is built as a modular monolith in Go over PostgreSQL, with eight Next.js portals, three long-running workers (relay, notifier, trust-consumer), a one-shot reconcile job, and an Expo mobile app. apps/api/internal/modules holds 52 modules; packages/contracts holds 53 OpenAPI documents and contracts/asyncapi holds 45 AsyncAPI documents. That is far more than the "Animal Digital Passport plus a web portal" this page described until 2026-08-28.

Breadth is not readiness, and the two must not be conflated:

Area	Status
Platform foundation (config, logging, http, tenancy, authz, outbox, audit, telemetry)	Implemented
Row-level security	Implemented — 73 tables carry ENABLE + FORCE ROW LEVEL SECURITY; the application connects as a NOBYPASSRLS runtime role. 33 of the 73 are exercised by the integration suite
Animal Digital Passport, Safety / Lost & Found, Organizations & Membership	Implemented; integration-tested
Eight web portals (web, admin, pro, seller, shelter, academy, connect, provider)	Deployed; each gated on lint + typecheck at image build
apps/mobile (Expo)	A real product, not a stub, and not released. 15 screens, offline cache, deep links, push registration — and it has only ever authenticated through the X-Debug-Actor development bypass, so it has never run against a non-development deployment. See ADR-031
OIDC/JWKS verification (Keycloak) & OpenFGA adapter	Implemented; unit-tested and live-verified locally against real Keycloak + OpenFGA (-tags=live_keycloak / -tags=live_openfga), on demand rather than automatically
Academy credentials (Open Badges 3.0)	Implemented; four public credential routes, per-country accreditation gating the claim (ADR-029)
apps/ai	Has a Dockerfile and health routes; nothing deploys it, and it exposes no business endpoint

For the checkbox-level truth of any domain, read ROADMAP.md. Summarizing it further here is what produced the version of this table that was wrong.

How anything gets verified

GitHub Actions does not execute for this project. The gates that do run are scripts/verify.sh (23 checks, on a developer's machine) and the per-image checks in each Dockerfile (on every Coolify build). See Build and deployment — read it before trusting any claim about a control on this site.

Local development

Local dev is turnkey for identity: the compose stack auto-imports a Keycloak realm with an audience mapper and a demo user; scripts/bootstrap-openfga.sh provisions the OpenFGA store and model. See Local Development.

See the Roadmap, the canonical ROADMAP.md, and the Production Readiness report — the last of which ROADMAP.md itself records as stale (dated 2026-07-27, still scoping the product as Passport plus web). Read it as a historical artefact, not as current status.

How this documentation is organized

• Product — vision and functional specifications.
• Architecture — style, ADRs, domain model, multi-tenancy, country policy, AI.
• API & Data — API guidelines, OpenAPI, database model, event catalog.
• Security & Privacy — baseline, threat model, privacy.
• Operations — Coolify deployment, local dev, build & deployment, monitoring, backup/DR, runbooks.
• Engineering — coding standards, testing, release process.