Files
breakpilot-compliance/backend-compliance
Benjamin Admin 1a9439d013 feat(programs): open Domain Knowledge Program v1 — 7-stage production line + per-domain KPI
The real bottleneck is domain MODELLING. Phase B is organized as one program with sub-programs per
domain, each run through the SAME 7-stage production line. No new runtime framework, no new module
(ADR-009, Freeze v1.0) — only program data + a derived reporting view.

- Customer enters by INDUSTRY, not regulation: Industry -> Domain Model -> Requirement Sources ->
  Requirements -> Capabilities -> ... -> Completeness.
- 7-stage checklist identical for every domain (Domain Model / Requirement Sources / Capability
  Registry / Transition Patterns / Playbooks / Reference Scenarios / Completeness) with per-stage
  ownership. README generalized to the framework.
- Each domain lists typical_requirement_sources + typical_certifications -> pre-onboarding capability
  HYPOTHESIS (the ETO insight; feeds Company 2A as inferred, never confirmed).
- Backlog v1 (by customer value): 1 Industrial Automation, 2 Environmental, 3 Automotive, 4 Medical,
  5 Energy. Five domain-definition shells (environmental restructured to the unified shape, law-first
  preserved).
- Per-domain KPI is DERIVED from the real corpus (computed-not-stored; sources modelled / transition
  patterns / playbooks / reference scenarios), NOT a curated number. Reference suite renders maturity
  bars: Industrial Automation 43% (3/7 sources) leads, Environmental 0% (work ahead). Backlog (value)
  and KPI (corpus state) are deliberately separated.
- ADR-009: Domain Knowledge Program framework. Honest known refinement: regulation-ID normalization
  (CRA vs Cyber Resilience Act) aliased in the KPI.

7 program-contract tests (backlog order + industry-first + derived-not-stored), check-loc 0.
Knowledge data + ADR + reference harness = non-runtime -> no deploy (ADR-001).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-27 18:49:06 +02:00
..

backend-compliance

Python/FastAPI service implementing the DSGVO compliance API: DSR, DSFA, consent, controls, risks, evidence, audit, vendor management, ISMS, change requests, document generation.

Port: 8002 (container: bp-compliance-backend) Stack: Python 3.12, FastAPI, SQLAlchemy 2.x, Alembic, Keycloak auth.

Architecture

compliance/
├── api/            # Routers (thin, ≤30 LOC per handler)
├── services/       # Business logic
├── repositories/   # DB access
├── domain/         # Value objects, domain errors
├── schemas/        # Pydantic models, split per domain
└── db/models/      # SQLAlchemy ORM, one module per aggregate

The service follows this layered target structure but not all files are fully refactored yet. Phase 1 backlog is tracked in .claude/rules/loc-exceptions.txt (27 backend-compliance files currently excepted).

See ../AGENTS.python.md for the full convention and ../.claude/rules/architecture.md for the non-negotiable rules.

Run locally

cd backend-compliance
pip install -r requirements.txt
export COMPLIANCE_DATABASE_URL=...  # Postgres (Hetzner or local)
uvicorn main:app --reload --port 8002

Tests

pytest compliance/tests/ -v
pytest --cov=compliance --cov-report=term-missing

Layout: tests/unit/, tests/integration/, tests/contracts/. Contract tests diff /openapi.json against tests/contracts/openapi.baseline.json.

Public API surface

404+ endpoints across /api/v1/*. Grouped by domain: ai, audit, consent, dsfa, dsr, gdpr, vendor, evidence, change-requests, generation, projects, company-profile, isms. Every path is a contract — see the "Public endpoints" rule in the root CLAUDE.md.

Environment

Var Purpose
COMPLIANCE_DATABASE_URL Postgres DSN, sslmode=require
KEYCLOAK_* Auth verification
QDRANT_URL, QDRANT_API_KEY Vector search
CORE_VALKEY_URL Session cache

Don't touch

Database schema, __tablename__, column names, existing migrations under migrations/. See root CLAUDE.md rule 3.