Benjamin Admin
ecae5bc7f1
Before the next Journey: the LANGUAGE. With 5 knowledge objects but no vocabulary, the same reise gets named four different ways (ISO9001->MaschinenVO vs Quality Management->Product Safety vs ...). The spec answers ONE question: which terms are IDENTITIES and which are REPRESENTATIONS of the same meaning? - spec docs-src/architecture/domain-vocabulary-spec-v1.md (PROPOSAL): identity hierarchy (Requirement RQ / Capability MCAP [Registry 2C] / regulation-source-target / Journey Class MJRN [PROVISIONAL] / Journey instance / Playbook MPLB); canonical name + aliases; capability vocabulary = the Capability Registry (not rebuilt); reorder Vocabulary -> Transition #2 -> #3 -> Rule of Three. - knowledge/vocabulary/regulations.yaml: regulation/standard IDENTITIES (id + canonical + aliases). SOLVES the regulation-ID normalization the KPIs flagged: CRA == "Cyber Resilience Act" == "Regulation (EU) 2024/2847" all resolve to `cra`; ISO9001/QMS -> iso9001; etc. Shared artifact (@Legal-KG/@Execution please adopt). - knowledge/vocabulary/journey_classes.yaml (PROVISIONAL): clusters our transitions into classes (Information Security -> Product Cybersecurity; Quality Management -> Product Compliance/Safety). Finding: ISO9001->MaschinenVO is an INSTANCE of an existing class (like ISO9001->CRA, ISO13485->MDR), not a new kind -> avoids duplication. Journey Class is a new abstraction -> its own Rule of Three (no MJRN minting yet). - reference suite: both KPIs now read aliases from regulations.yaml instead of hard-coded maps; the "Regelwerk-ID-Normalisierung" line flips TODO -> PASS. KPI numbers unchanged (vocab is a superset). - Side effect = Requirements Intelligence: a Tender "Security Patch Procedure" resolves to MCAP-0017. 7 vocabulary tests (17 with domain programs), check-loc 0. Knowledge data + spec + reference harness = non-runtime -> no deploy (ADR-001). No new module, no runtime change, no minting (Freeze). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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.