Inspect the source, test conditions and operating limits in the technical record.
Explore the technical record and evidence
Business ↔ technology bridge · Governance capability experiment
Turn regulatory obligations into owned product and evidence work.
Explores evidence-linked regulatory workflow without presenting generated guidance as legal authority.
This is a portfolio and source interpretation—not a customer, deployment, certification, or outcome claim.
01
Business pressure
System inventory, risk classification, evidence, remediation, and reporting are often fragmented across legal, compliance, product, and engineering teams.
02
Product decision
Separate deterministic inventory and workflow state from retrieval-assisted interpretation, and preserve named human review points.
03
Technical record
Inventory, retrieval, classification, evidence, remediation, audit, and report modules with migrations and selected mocked test seams.
04
Evidence return
Evidence gaps and classification uncertainty return to product scope, control design, accountable owners, and release planning.
Repository/runtime boundary
This page interprets source from a separate venture repository. Source presence does not make the venture a service running inside hyperion-consulting.io.
Visitor and client-data AI processing is restricted to Mistral through the governed EU endpoint. Owner-authorized Helio, Search and Product Council paths are enabled. A separate public-source editorial lane uses Anthropic with governed Mistral backup; it receives no website enquiries, client documents or visitor conversations. Deterministic tools remain available when remote AI is unavailable.
Source evidence
What the source actually establishes
A regulatory-workflow backend prototype with inventory, retrieval, classification, evidence, remediation, audit, and report modules. It is a decision-support system under development, not legal advice or a conformity assessment.
Maturity
Development prototype
Evidence review
Source snapshot through
Architecture and product decisions
Separate deterministic system inventory and workflow state from retrieval-assisted regulatory interpretation.
Link evidence chunks and report snapshots to the decisions they support.
Preserve human review points for classification, remediation, and regulatory reporting.
Inspectable evidence
FastAPI modules and SQL migrations covering the principal workflow and data boundaries.
Pytest coverage for selected API, data, classification, report, and remediation paths.
Regulatory-corpus ingestion and retrieval plans with mocked integration seams in tests.
Claim boundary
The test record relies substantially on local and mocked integrations.
No claim of complete regulatory coverage, legal accuracy, live monitoring, conformity, or certification is made.
An accountable legal, compliance, and system owner must review any generated assessment or document.
Repository evidence is not client, deployment, certification, or outcome evidence.
Architecture
From regulatory text to structured, evidence-backed reporting
Three source layers: regulatory feed monitoring, retrieval-assisted obligation extraction, and a tamper-evident audit chain. Regulator acceptance of any record must be assessed separately.
Source map only: a layer can represent implemented code, an adapter boundary, or documented design. It does not assert a configured production service.
01
Layer 1 — Regulatory Monitoring
The source represents three EUR-Lex ATOM feeds (EU AI Act, GDPR, AI General), parsing of new instruments by CELEX, severity extraction (critical/high/low), and a Mistral impact-analysis step against the registered AI-system inventory. No live monitoring is claimed.
02
Layer 2 — Compliance Engine
The source represents Mistral + RAG over a corpus of Articles, Annexes, and EDPB guidance: obligation extraction, cross-regulation overlap mapping (AI Act ↔ GDPR ↔ NIS2), risk classification, and gap analysis, with confidence scores and Article-level citations. Outputs require expert review.
03
Layer 3 — Tamper-Evident Audit
The source models classification, gap, remediation, timestamp, and reviewer records in an audit chain. Whether an exported record meets a legal or regulator requirement must be assessed separately.
EU AI Act coverage
Ten high-impact AI Act articles represented in the prototype
Compliance theatre is a list of articles in a PDF. Compliance practice is each article mapped to a specific AI system, with evidence, owner, and last-review date. Below: the articles the prototype represents per registered system. Extracted obligations require expert review.
Repository surface only: availability, completeness, performance, and operational fitness require separate validation.
ART. 4
AI Literacy
01
The source includes role-based literacy tracking, quiz, and record-generation workflows. It does not certify a person's competence or an organisation's Article 4 compliance.
ART. 5
Prohibited Practices
02
A rule and retrieval workflow maps a registered system against prohibited-practice categories and references. Legal classification remains a human decision.
ART. 6
High-Risk Classification
03
The source represents an Annex III risk-class assessment with Mistral-generated reasoning, a confidence score, and a per-Annex obligation tree. It is designed to re-run on registry events (model swap, scope change, training-data update).
ART. 9
Risk Management System
04
Continuous identification, estimation, evaluation, and treatment of risks. The prototype is designed to link each identified risk to its mitigation control and to take evidence from a CI pipeline (test pass/fail, model card, eval suite). No live integration is asserted.
ART. 10
Data Governance
05
Training, validation, and testing datasets with representative coverage, bias detection, and lineage. The prototype is designed to cross-reference a dataset registry against the Annex IV technical-documentation requirements.
ART. 11
Technical Documentation
06
Annex IV technical file: system purpose, design, training methodology, performance metrics. The prototype is designed to generate the document skeleton, fill in evidence from the registry, and flag missing sections per Annex IV.1–9. Drafts require accountable review.
ART. 12
Record-Keeping & Logs
07
The prototype represents event-schema and audit-record checks for registered systems. It does not establish that an external operational pipeline emits complete or legally sufficient logs.
ART. 13
Transparency
08
Instructions for use, including intended purpose, accuracy, robustness, foreseeable misuse, and human-oversight measures. The prototype is designed to draft the deployer-facing transparency notice against an Article-13 checklist.
ART. 14
Human Oversight
09
Effective oversight measures designed into the system. The prototype is designed to evaluate an oversight design against four capabilities drawn from Article 14 (understand, monitor, override, disable) and to produce a gap analysis for review.
ART. 15
Accuracy, Robustness, Cybersecurity
10
Performance metrics, robustness to errors, faults, inconsistencies; cybersecurity against adversarial attacks. The prototype is designed to collect eval-suite results, red-team reports, and an SBOM into the Annex IV evidence block. No live integration is asserted.
Tech Stack
Built With
Named technologies identify repository dependencies or adapter surfaces; they do not assert a live integration or deployment.
Backend
Python, FastAPI, PostgreSQL, Redis, SQLAlchemy and Alembic