Zum Inhalt springen

Unabhängiges F&E-Projekt · Köln

Forschungsüberblick

Research architecture

Open Template Library

A library of reusable implementation patterns for the safeguards, controls and evidence that COADF 2.2 describes. Each template is written once and generated three ways: for tools, for AI agents and for people.

Status: Pilotkatalog · Prototyp

Diese Seite ist auf Englisch verfügbar.

Published templates

5

Published and validated, counted from the generated registry rather than written here.

A template helps implement a control. It settles no legal question on its own, and whether it applies always depends on the system it is used in.

The catalogue

Choose a template, then a representation. All three come from the same source file, and the generator checks that they agree before anything is published.

Template

Human review at field level, against the source, with a recorded decision

Uncertain fields go to a person who sees the source beside the proposed value, may accept, correct or reject it, and whose decision is recorded.

Version
1.0.0 · published · COADF 2.2
Requirements
3 MUST · 1 MUST NOT
Mapped controls
  • P-3-alo-decision-layer (P-3) Review happens at attribute level, a rejected value leaves the attribute empty, and every human decision is recorded with its actor.
Source SHA-256
3837cf8db6aeba0248a2155339a09f743fbcbfdf005250b8a1f0019256a899c7
Representation

guide.md: the problem, each requirement with how to check it, a worked example, a checklist and the limits.

attribute-level-human-review · version 1.0.0 · published · COADF 2.2 · principles P-3

Uncertain fields go to a person who sees the source beside the proposed value, may accept, correct or reject it, and whose decision is recorded.

A template helps implement a control. It settles no legal question on its own, and whether it applies always depends on the system it is used in.

The problem

Human review often means a person clicking through whole documents, approving what a system already decided. Without the source in front of them, the reviewer checks the system against itself; without a record, nobody can later tell who decided what, or on which evidence.

What the pattern achieves

A person decides each uncertain field against its source, a rejected value leaves the field empty rather than falling back to a guess, and every decision is recorded with who, when and which source was checked.

When it applies

  • Some fields cannot be settled automatically and a person has the authority to settle them.
  • Decisions about those fields must be reconstructable later.

When it does not

  • No field ever needs a human decision.
  • The person reviewing has no access to the source the value came from.

Requirements

R1 · MUST

The review queue works per field, not per document, and shows the source next to the proposed value.

Why: A reviewer can only verify a value against the evidence it came from.

How to check: The review interface for one item shows exactly one field and a link to or view of its source.

R2 · MUST

A rejected value leaves the field empty; the system never substitutes another guess.

Why: Replacing one rejected guess with another turns review into a loop of guesses.

How to check: A test rejects a proposed value and asserts the field is empty afterwards.

R3 · MUST

Every decision is recorded with the reviewer, the time, the decision and the source that was checked.

Why: A decision that cannot be traced cannot be relied on or corrected.

How to check: A test records a decision and asserts the record carries reviewer, timestamp, outcome and source reference.

R4 · MUST NOT

An output that still has an unresolved review item is released.

Why: The review exists to stop exactly that release.

How to check: A test leaves one review item open and asserts the release step refuses.

Worked example

A decision record

{
  "item": "shipment-2291/origin_country",
  "proposed": {"value": "BR", "method": "ocr", "confidence": "LOW"},
  "decision": "corrected",
  "value": "PY",
  "reviewer": "reviewer-17",
  "decided_at": "2026-09-16T10:42:00Z",
  "source_checked": "document://shipment-2291/certificate.pdf#page=2"
}

One field, one decision, with the proposed value kept beside the decided one, and the exact source page the reviewer looked at. An identifier stands for the reviewer rather than a name.

Checklist

  • R1 (MUST): The review queue works per field, not per document, and shows the source next to the proposed value.
  • R2 (MUST): A rejected value leaves the field empty; the system never substitutes another guess.
  • R3 (MUST): Every decision is recorded with the reviewer, the time, the decision and the source that was checked.
  • R4 (MUST NOT): An output that still has an unresolved review item is released.

Evidence to keep

  • The decision records, append-only, with reviewer, time and source reference.
  • The tests for rejection leaving the field empty and for release refusing with an open item.

Limits

  • Using this template does not establish that human oversight meets any legal requirement, and it has no legal effect on its own.
  • Who may review what is an authority decision for each organisation; this template records it, it does not grant it.

Reassess when

  • The set of fields that can go to review changes.
  • Reviewer roles or authority change.
  • The release step changes.

Mapped COADF controls

  • P-3-alo-decision-layer (P-3): Review happens at attribute level, a rejected value leaves the attribute empty, and every human decision is recorded with its actor.

Provenance

  • docs/coadf/COADF.md, P-3: Human in the loop by architecture, checked 2026-09-16

Changelog

  • 1.0.0 (2026-09-16): First published version.

One source, three representations

One semantic source

  • Machine-readable: the template as JSON, with the controls it maps to resolved, and a JSON Schema for the source format.
  • AI-readable: a structured contract an agent can follow without guessing.
  • Human-readable: an implementation guide with examples and a checklist.

The three are generated from the source by scripts/coadf_templates.py rather than written three times, and a check fails if any generated file differs from what its source produces, so they cannot drift apart.

What every template carries

  • A semantic version. A published version is locked by the hash of its source, so a change is a new release, never an edit to an old one.
  • Where each requirement came from in COADF 2.2, and the date that source was last checked.
  • A lifecycle status, from draft through published to superseded; a published template cannot return to draft.
  • Tests that plant each defect the generator must refuse and confirm it is refused.
  • An entry in the registry, with the hash of each generated file.
  • A mapping to COADF controls that exist in the conformance manifest and serve one of the template's principles.
  • Migration notes, required for every version after the first.

Where it stands

A pilot catalogue of 5 published templates, grown one validated template at a time. The generator refuses a template that maps to a control COADF does not have, maps a control serving a different principle, changes a published version in place, or presents itself as settling a legal question. Using a template has no legal effect on its own. An earlier planning document referred to a much larger catalogue that was never built; this page does not repeat the figure.

Forschungsprojekt · Unabhängige F&E · Kein kommerzielles Angebot