Software Architect · Cologne
Luiz
HogrefeArchitecture for AI systems that have to remain understandable, governed and verifiable.
I design software systems in which architecture, AI, semantics and verifiable evidence have to work together. I have been building software since 2008, first in Brazil and, since 2014, in Germany.
Based in Cologne · Working across architecture, AI and interoperability
› event supplier.certificate.expiring t-3d“A supplier certificate expires in three days”
- ACT0.61
- WAIT0.31
- ESCALATE0.09
- ✓ Hard limit
- ✓ Evidence not contradicted
- ✓ Qualification confident enough
- ✗ Evidence present
› outcome ASKActing would need evidence that is not there yet. The runtime asks for it.
§ 01Live runtime
Rhythm influences qualification. Constraints govern operation.
This is the idea at the centre of my current research, running in your browser. A probabilistic step ranks what looks appropriate next. A deterministic operator then checks limits, evidence, authority and time, and only what passes goes ahead. Move the rhythm and the probabilities change. Remove the authority and no probability can make the action happen.
- 01
ERQ qualifies
The Event Rhythm Qualifier reads the event, the state and the rhythm, and ranks candidate outcomes with probabilities.
- 02
YO operates
The Yoked Operator is bound to authoritative constraints, not to the qualifier. Its rules run in a fixed order, and the first one that fails decides.
- 03
The decision is explained
Every outcome carries the rule that produced it, so it can be read, questioned and replayed.
› event supplier.certificate.expiring t-3d
ERQ · proposed
- ACT61%
- WAIT31%
- ESCALATE9%
YO · decided
- ✓ Hard limit
- ✓ Evidence not contradicted
- ✓ Qualification confident enough
- ✗ Evidence present
outcome
ASKRequired input or evidence is missing
Acting would need evidence that is not there yet. The runtime asks for it.
ERQ: ACT → YO: ASK
An illustration computed in your browser: a simplified model of the ERQ → YO separation with illustrative numbers and eight of ERQYO's ten outcomes. It is not the ERQYO reference implementation.
§ 02Selected areas
Where I work
Software architecture
System boundaries, integration models and decisions written down so they can be reviewed, tested and handed over.
Professional historyAgentic and governed AI
Architectures in which models do bounded work while deterministic rules decide, keep a record and can be replayed.
ERQYOSemantic interoperability
Shared vocabularies such as ECLASS and the Asset Administration Shell, so that a field means the same thing at both ends of an exchange.
ResearchDistributed systems
Event-driven backends in Java and Python, and the delivery pipelines that keep them releasable.
CVTraceable evidence
Provenance, custody and audit trails that travel with the data, so that a claim can be checked instead of believed.
Trust ArchitectureDigital product passports
Architecture and data models for passports under European product law, from source documents to a published structure.
AnyDPP
§ 03Selected work
Things you can inspect
Research artefacts and implementations, each labelled with how far it has actually gone. A framework is not a platform, and a prototype is not a product.
ERQYO
01Reference implementation · not deployedA runtime architecture in which learned rhythm may shape a proposal, while authority, policy, evidence and hard time limits decide what operates.
Read more : ERQYOCOADF
02Published frameworkThe Compliance-Oriented AI Development Framework, version 2.2: eight principles for building AI-assisted software under explicit, testable governance.
Read more : COADFAnyDPP
03Research and demonstration environmentA research and demonstration environment in which source documents become evidence, pass human review and are composed into a digital product passport.
Read more : AnyDPPTrust Architecture
04Implemented platform architectureHow confidence per attribute, human review and a hash-chained audit trail fit together when data crosses organisational boundaries.
Read more : Trust ArchitectureAnyImob
05Applied implementation · historical lineageAn earlier applied implementation: an assistant for real-estate brokerage with grounding checks, guardrails, handoff to people and audit logs.
Read more : AnyImob- All research All projects
§ 04Research thesis
“What changes in software architecture when AI can increasingly produce the implementation itself?”
My working answer is that architecture does not disappear. It moves. The judgement that used to live implicitly in the way people wrote code has to become explicit enough for a machine to be held to it.
- 01
Automation does not remove architecture
Generated code still has boundaries, dependencies and failure modes. Someone decides them, or they get decided by accident.
- 02
Intent has to become explicit
What a system is for, and what it must never do, has to be written where both people and tools can read it.
- 03
Constraints have to be executable
A rule that exists only in a document is a wish. A rule that runs in the pipeline and blocks a release is architecture.
- 04
Meaning has to survive boundaries
Data crosses systems, organisations, languages and jurisdictions. If its meaning shifts on the way, correctness at each end does not help.
- 05
Evidence is part of the design
Where a value came from, who checked it and under which rule version belongs in the system, not in a report written afterwards.
- 06
Authority stays apart from inference
A model may propose. Permission to act comes from a mandate, a policy or a person, never from a confidence score.
§ 05Career
Eighteen years, two countries
A short version. The full history, with roles as the employers named them, is on the Work page.
2008
Software engineering in Brazil
Web systems for academic and financial administration in Blumenau, and a Bachelor of Computer Science.
2014
The move to Germany
Java development in Berlin, then software development in Düsseldorf.
2017–2022
Sopra Steria
Consultant in enterprise projects for energy, banking and automotive clients.
2023–2024
msg
IT consultant in Cologne: development, Scrum Master and test management.
2026
IW Consult
Software architect in the Standards division, working on digital product passports and ECLASS.
2026–
Independent R&D · AnyLAI
Frameworks, runtime research and demonstrations, published on anylai.eu.
§ 06Writing
Selected writing
Articles on architecture, AI governance, product passports and evidence. They are published on anylai.eu, which remains their canonical home.
24 min read
Less human coding, more human architecture
As AI produces more software implementation, engineering effort may shift toward architecture, executable constraints, verification and evidence. A research thesis, with its evidence and its limits.
ArchitectureAgentic AI
anylai.eu ↗ (on anylai.eu)
11 min read
AI governance needs architecture, not another checklist
Governance holds when the architecture can enforce it. COADF sets out eight principles for deterministic controls, probabilistic AI, evidence and human review.
AI governanceArchitecture
anylai.eu ↗ (on anylai.eu)
9 min read
Battery Passport: what the Commission's 71 data points mean for 2027
The European Commission has structured 71 data points for the Digital Batteries Passport. What changes, what stays fixed for 18 February 2027, and how manufacturers and importers can prepare the evidence behind each field.
Digital product passportsRegulation as engineering input
anylai.eu ↗ (on anylai.eu)
9 min read
Custody is not who held it. Custody is who can prove it.
Chain of custody as it is practised today is a chain of declarations reconciled by periodic sampling. European rules are moving, one instrument at a time, toward asking questions that only a chain of evidence can answer, and the moment of discovery matters: at the border it is too late.
Evidence and trust
anylai.eu ↗ (on anylai.eu)
Contact
Architecture, AI systems or research?
If you want to talk about a role, an architecture problem or the research, write to me. I read and answer every message myself.