THE PLATFORM
The AI governance platform that produces the substantive artefact.
Hael is not a documentation tracker and not an MLOps tool. It is the methodology engine that generates Annex IV technical files, AI RMF profiles and AIMS records from live operational state — sealed with hash-chained provenance, ready for the regulator.
HOW IT PRODUCES THE ARTEFACT
Three stages. One sealed artefact at the end.
01 — INGEST
Live operational state, not document uploads.
Hael ingests directly from the systems where AI is built, deployed and monitored — model registries, training data lineage, evaluation harnesses, monitoring telemetry, incident chains, vendor attestations and human-oversight records. No document tracker. No questionnaire fatigue. The substantive evidence that the regulator's standard of proof actually requires.
02 — APPLY
Methodology engine, applied clause by clause.
The Hael Methodology Standard maps every clause of every in-scope framework — Article 11 of the EU AI Act, Annex A of ISO/IEC 42001, the GOVERN/MAP/MEASURE/MANAGE functions of NIST AI RMF, Article 27 fundamental-rights impact assessments, Colorado SB 24-205 algorithmic-impact obligations — to specific operational data sources and a defined evidentiary standard. Generation is not template fill. It is methodology execution against verified state.
03 — SEAL
Hash-chained, version-pinned, regulator-ready.
Every generated artefact is sealed: methodology version, source-state snapshot, SHA-256 chain back to the previous artefact in the same lineage, signed manifest. The regulator does not have to trust Hael's claim that the document reflects the system. They verify the cryptographic proof. The same standard that capital-markets infrastructure already uses for trade reporting — applied to the AI governance artefact.
Tooling, evidence aggregation and tracking are by-products. The artefact is the product.
WHAT IT PRODUCES
Six artefact types. The substantive deliverables your regulator actually opens.
ARTICLE 11 TECHNICAL FILES
EU AI Act Annex IV
Complete Annex IV technical documentation — system description, design specifications, risk management system per Article 9, data governance per Article 10, transparency per Article 13, human oversight per Article 14, accuracy and robustness per Article 15. Generated as the file the notified body opens, not as a tracker of policy gaps.
FUNDAMENTAL RIGHTS IMPACT ASSESSMENTS
EU AI Act Article 27
Article 27 FRIAs for high-risk deployers. Process description, foreseeable impact on fundamental rights, categories of natural persons affected, specific risks of harm, human-oversight measures, redress mechanisms. Generated against the deployment context the system actually operates in, not against a generic template.
AIMS RECORDS
ISO/IEC 42001
AI management system records aligned to ISO/IEC 42001 Annex A controls — context of the organisation, leadership, planning, support, operation, performance evaluation, improvement. The certifiable evidence base your auditor scopes against, not the policy library.
AI RMF PROFILES
NIST AI RMF 1.0
GOVERN, MAP, MEASURE, MANAGE profiles published as substantive artefacts. The voluntary baseline US federal procurement and the US Treasury Financial Services AI RMF map onto. Generated with the operational evidence each function expects, not with attestation prose.
ALGORITHMIC IMPACT ASSESSMENTS
Colorado SB 24-205, NY RAISE, NYC LL 144
Algorithmic impact assessments and consumer-facing notices for the US sub-federal regime — Colorado AI Act §6-1-1701, NYC Local Law 144 bias audit summaries, New York RAISE Act safety evaluations. Each artefact generated to its statute's evidentiary standard, not flattened to a common denominator.
POST-MARKET MONITORING REPORTS
EU AI Act Article 72
Article 72 post-market monitoring plans run continuously, with the periodic monitoring report generated against live performance, incident and drift telemetry. Article 73 serious-incident reporting flows wired to the right competent authority within statutory deadlines, hash-chained from observation through notification.
METHODOLOGY
The standard a competent authority recognises.
Hael does not generate against a template. It generates against a methodology — a documented standard, versioned and published, that maps every clause of every in-scope framework to a specific operational data source and a specific evidentiary threshold. The methodology is the contract between the platform and the obligation. When Article 11 of the EU AI Act demands a description of the data sets used in training, validation and testing, the methodology specifies which fields the model registry must surface, which lineage proofs the data warehouse must produce, and which calibration evidence the evaluation harness must seal — all before a single line of artefact prose is generated.
This is the standard that distinguishes a regulator-recognised submission from a documentation exercise. Notified bodies under the EU AI Act, accredited certification bodies under ISO/IEC 42001, examiners under SR 26-02 and supervisory teams under the FCA's evolving AI guidance do not assess intent. They assess the artefact against an evidentiary standard. The methodology is what makes Hael's output meet that standard at the layer the auditor actually examines.
Methodology versions are published, dated and immutable. Every sealed artefact carries the methodology version it was generated against. When the regulation moves — when the EU AI Office publishes a delegated act, when ISO updates Annex A, when SR 26-02 attaches new supervisory expectations — the methodology version increments and prior artefacts remain verifiable against the methodology in force at their date of seal. That is the standard a competent authority recognises.
METHODOLOGY TRACE
Every line of generated prose, traceable back to the regulatory clause and the operational data source.
REGULATORY CLAUSE
GENERATED ARTEFACT — §2(B)
The Candidate screening model AIS-014 system implements a gradient-boosted classifier trained on 482,116 anonymised credit applications collected between Q1 2024 and Q3 2026, with feature engineering described in the referenced data sheet. Decision boundaries are calibrated against the equalised-odds constraint defined in the model card and re-tested at each retraining cadence.
OPERATIONAL SOURCE
AUDIT CHAIN
Hash-chained from observation to regulator notification.
Every state transition — risk classification change, evidence ingestion, control execution, incident escalation, artefact sealing — produces an immutable audit entry. Each entry references the SHA-256 of the previous entry.
The chain is verifiable in seconds. Tampering is mathematically detectable. When a competent authority opens a Hael artefact, they aren't trusting our claim that the evidence is real. They are verifying a cryptographic proof that the artefact has not changed since the moment Hael sealed it.
This is the standard the EU AI Act, ISO/IEC 42001 and the US Treasury FS AI RMF gesture toward. Hael ships it.