Skip to content
Luiz Hogrefe

COADF

Compliance-Oriented AI Development Framework · version 2.2

Published framework

COADF is a development framework for AI-assisted software that has to hold up under European regulation. It turns governance into things a pipeline can run: principles, controls with evidence, and fences that block a release.

The research problem

AI-assisted software is increasingly built under rules such as the EU AI Act, while the governance around it often lives in policies and checklists that the code never sees.

COADF asks what it takes for governance to hold in the architecture itself: in pipelines, data models, review steps and records.

Eight principles

The published names of version 2.2, each condensed to what it requires.

  1. P-1

    Deterministic first, probabilistic quarantined

    What reaches a person, a document or another system is deterministic by default. Machine learning is held to bounded tasks and returns a value together with its confidence and its extraction method.

  2. P-2

    Confidence-gated output

    Confidence attaches per attribute, in three levels. The lowest never reaches a published output, and missing evidence yields a missing value.

  3. P-3

    Human review by architecture

    Review is triggered by the architecture, at attribute level, with the source beside the value. A rejected value leaves the attribute empty.

  4. P-4

    One trace, end to end

    One identifier follows a value from intake to published output, in an append-only trail that a single query can reconstruct.

  5. P-5

    Disclosure of machine extraction

    Every attribute records how it was extracted, and machine-derived values are disclosed on the document they appear in.

  6. P-6

    The fence system

    Guardrails run in the pipeline and block a release. Each one needs a proof of teeth: plant the defect, watch the fence fire, revert.

  7. P-7

    Standards dependency isolation

    External vocabularies and services live in adapter modules. An external service can raise confidence, but it can never gate output.

  8. P-8

    Policy as data, with graduated autonomy

    Rules are data, bound to a version in every decision record. Autonomy is set per jurisdiction and risk class, never above the legal ceiling.

In version 2.2, the fifth principle is only partially enforced: the recording half is enforced, the rendering half is recorded as a gap.

Conformance, stated honestly

A machine-readable manifest lists every control together with the command that produces its evidence. Running it writes a dated report.

A control marked as enforced whose evidence did not run, or ran and failed, fails the whole run. The report is self-attested by whoever runs it, and it says so.

controls in version 2.2
58
enforced
44
manual
5
recorded gaps
9

Fences

Fences are automated checks that block a merge or a release. They cover data, architecture, public copy and process, and the registry numbers them from F-01 to F-43.

Some of them guard exactly the kind of claim this page avoids: public copy must not assert legal conformity, and every public factual claim has to resolve to a source or a named test.

Candidate practices

Four further practices are published as candidates. They are not numbered principles.

  • Claim discipline
  • Non-override
  • Evidence semantics
  • Disclosure control

What COADF is not

What COADF is not

  • Not a certification, an audit standard or a conformity assessment scheme.
  • Not assessed, audited or endorsed by any authority.
  • Not a statement that any system, output or shipment is compliant.
  • Not yet licensed for reuse: a licence has been proposed, not granted.

Where it sits

COADF is the development method behind AnyDPP and the governance frame for the rest of AnyLAI's research. ERQYO describes how a runtime decides under that governance; the Trust Architecture shows the principles running across organisational boundaries.

Version 2.2 was made public on anylai.eu on 10 September 2026, in five languages, together with a non-normative Engineering Companion.

  • Trust ArchitectureImplemented platform architecture

    Provenance, evidence, confidence, authority and audit, arranged so that trust can be checked at every boundary.

    Trust Architecture
  • AnyDPPResearch and demonstration environment

    Source documents become evidence, pass human review and are composed into a digital product passport.

    AnyDPP
  • ERQYOReference implementation · not deployed

    A runtime architecture that lets learned rhythm shape a proposal while authoritative constraints decide the operation.

    ERQYO