AnyLAI · Cologne
Architecture for verifiable and governed AI systems.
AnyLAI is an independent R&D project exploring how evidence, semantics, AI governance and product data can remain traceable and verifiable across systems, organisations and jurisdictions.
Areas of work
- Architecture
- Verifiable evidence
- AI governance
- Semantic interoperability
- Digital Product Passports
Research thesisLess human coding, more human architecture
Research
Research, runtime, evidence and applied systems
Each part is published at the depth at which it can be checked, and each states its status: a framework to read, a runtime to inspect, an evidence architecture, a template library in design, and applied systems that test them on real material.
The question behind all of it: what happens to software architecture when AI can increasingly produce the implementation, and which parts of human intent have to become explicit, testable and enforceable for a system to stay under control, whoever or whatever wrote its code?
Architecture and governance framework
COADF
Compliance-Oriented AI Development Framework
Published framework
The publicly documented framework: eight architecture principles, governance templates and a machine-readable model for reporting which controls a project actually exercises.
Adaptive Decision Runtime
ERQYO
Research architecture · reference implementation
A research architecture for deciding what an AI system should do next and under whose authority. A reference implementation exists in the repository; it is not deployed.
Evidence and provenance
Trust architecture
Implemented platform architecture
How evidence and meaning survive across system and organisational boundaries: confidence per attribute, a person where the evidence is uncertain, and one trail from the source document to the published output. The Trust Corridor is that path across organisations and jurisdictions.
Pilot catalogue
Open Template Library
Pilot catalogue · prototype
Reusable implementation patterns for COADF controls, each generated machine-, AI- and human-readable from one source and validated against the conformance manifest. A small first catalogue.
Applied research
Applied research
Systems that test the architecture on real documents and workflows: AnyDPP, AnyAudit and AnyImob run today, and six research concepts are under way.
The architectural problem
Proving the output is no longer enough.
Systems increasingly need to prove not only what they output, but where information came from, what was inferred, what was verified and what a person decided.
That record has to hold across the boundaries it crosses: between software components, between organisations, and between jurisdictions with different rules. This project treats it as a question of architecture, not of documentation after the fact.
AI can increasingly produce parts of the implementation. The harder problem is making sure the resulting system preserves the properties that actually matter: where its data came from, what it may infer, what it must refuse to do, and what evidence it leaves. Less human coding, more human architecture
- Where did the information come from?
- What did a machine infer?
- What was verified, and against what?
- What did a person decide?
Public framework
COADF
Compliance-Oriented AI Development Framework
COADF is a development method for AI systems that have to hold up under European regulation.
It states eight architecture principles, each tied to the obligation it was written against, with governance templates and a machine-readable model for reporting which controls a project actually exercises.
The eight principles
P-1 · Deterministic first, probabilistic quarantined
Deterministic processing by default. A probabilistic component is bounded and never reaches an output directly.
P-2 · Confidence-gated output
Confidence attaches to one attribute at a time, and low confidence never reaches a published output.
P-3 · Human review by architecture
Where confidence is insufficient a person decides, at attribute level, against the source.
P-4 · One trace, end to end
One identifier links ingestion, every step and the published output, and the chain exports.
P-5 · Disclosure of machine extraction
An output carrying machine-extracted data says so, and names which attributes.
P-6 · The fence system
Guardrails are automated checks that block a release, not advice in a document.
P-7 · Standards dependency isolation
An external service can raise confidence. None of them can gate an output.
P-8 · Policy as data, with graduated autonomy
Rules are data, the engine does not change when a rule changes, and a decision is bound to the rule version that produced it.
Version 2.2 · September 2026. COADF is publicly documented as a development framework. No authority has assessed, audited or endorsed it.
Launch articleAI governance needs architecture, not another checklist
First concrete application
From architecture to a real trade corridor
One place where these ideas become concrete is the Brazil-EU evidence corridor: coffee, Brazilian export documents and the EUDR.
Compliance is becoming the common language of multipolar trade.
AnyLAI turns Brazilian export documents (NF-e, CAR, MAPA) into verified EUDR evidence and Digital Product Passports built on UNTP and W3C Verifiable Credentials.
Brazil is the EU's largest coffee supplier, and Germany is its largest single buyer. AnyLAI starts where that trade is busiest: the evidence corridor between Brazilian origins and European roasters.
Which of the two are you?
5.4M · 13.5%
Germany = #1 buyer of Brazilian coffee 2025 · 5.4M bags · 13.5% of Brazil's exports (Cecafé)
US$15.5–15.6B
Brazil 2025 coffee exports: record ≈US$15.5–15.6B (Cecafé)
34.2%
EU coffee imports 2025: 2.86M t · €18.7B · Brazil #1 supplier (34.2%)
Trust
Trust architecture
In simple terms: the system never just says yes or no. It shows how confident it is in each piece of evidence, and sends anything uncertain to a qualified person to check.
Confidence is assessed per attribute, never as a blanket verdict. High confidence flows automatically; medium confidence is flagged and contextualized and still publishes; an unresolved low-confidence attribute holds issuance of the whole passport until a registered human attester resolves it.
A hash-chained audit trail carries the same trace_id (the identifier tying one evidence trail together, end to end) from ingestion through to the published passport: each entry is linked to the one before it, so editing an earlier entry is detectable by recomputing the chain. The chain is not yet anchored outside the system.
Regulatory trajectory
Published dates, and frameworks still being built
Every date above is a published regulatory milestone. Where a framework is still being built, this page calls it a trajectory, not a settled fact.
Source: Regulation (EU) 2023/1115, Article 38(2) and (3), as replaced by Regulation (EU) 2025/2650, Article 1, point (25) (primary source) · checked on 6 September 2026
Source: Regulation (EU) 2023/1115, Article 38(1) and (2) (Articles 14 and 25 are outside the deferred list), as replaced by Regulation (EU) 2025/2650 (primary source) · checked on 6 September 2026
Source: Commission delegated act of 13 July 2026 amending Annex I to Regulation (EU) 2023/1115 (no OJ number yet), Regulation (EU) 2023/1115, Article 36(4) and (5) (scrutiny); Annex I (primary source) · checked on 23 August 2026
Every deadline on the RadarThe EUDR dates in the Brazil-EU corridor
Research and analysis
Recent technical writing
Less human coding, more human architecture
AI can increasingly produce parts of a software system's implementation. Producing more of it does not settle what the system must preserve. A research thesis about where engineering effort moves, the evidence behind it, and what it does not claim.
AI governance needs architecture, not another checklist
Policies and checklists describe how an AI system should behave. Whether it does is decided by its architecture: where uncertainty is represented, which boundaries it cannot cross, and what the system keeps as a record.
Battery Passport: what the Commission's 71 data points mean for 2027
The obligation is not new. What is new is that the Commission has set out, field by field, what the passport is expected to hold and which fields matter at the first stage.
About
About this project
AnyLAI is built by Luiz Hogrefe, a software architect based in Cologne. It is one person's work, and it is written down in the open rather than described from a distance.
What it demonstrates is narrow and checkable. Brazilian export documents are read deterministically, every attribute carries the source document behind it and a confidence level, an unresolved low-confidence attribute holds issuance of the whole passport until a registered human attester resolves it, and the result is issued as a product passport that verifies against the credential itself rather than against a page on this site.
What it is not: not a company, not an offer, and not a service anyone can buy. No company has been formed, nothing here is for sale, and no page on this site should be read as availability.
The standards it builds on are public: the UN/CEFACT UNTP Digital Product Passport profile, W3C Verifiable Credentials and GS1-compatible identifiers. The architecture and governance method behind it is published as the AnyLAI COADF framework.
More about Luiz HogrefeLuiz Hogrefe on LinkedInIP and publication status
About
Project status
The EUDR deadline is fixed; the evidence work behind it is not. This project exists to test one question in the open: whether the documents an exporter already issues can become evidence a buyer, an auditor or an authority is able to check without having to trust whoever produced it.
AnyLAI is an independent research and development project by Luiz Hogrefe, Cologne. The demonstration passport is live; its signature can be checked against the issuer key published at did:web:anydpp.eu, and the passport page states what that check does not yet show. Feedback and evaluation conversations are welcome.
Feedback, questions and evaluation conversations are welcome at any time.
Get in touchPublic feedback
Public Feedback & Discussion
AnyLAI publishes technical work so that its assumptions, sources and architectural decisions can be inspected and challenged. Feedback submitted here is reviewed before publication and remains linked to the version or article it addresses.
About
Get in touch
Have a question, a comment on the method, or something to flag? Send a message below. Name, email and message are all it asks for.