Put the direction in — as one prompt
Apply is the step that returns the results of Set, Log, and Analyze into a live AI. A group that has just set its hierarchy can start now: the setting and the logging instruction, bundled into a single system prompt.
AIO 20004 — return Set / Log / Analyze results into the running system
The standard number is the goal statement. The digits 2·00·0·4 say whose values, in which domain, and which action this document covers.
Organization — teams, institutions, communities
Common — domain-independent
Base document
Apply — return the results into the system
What this standard defines — the procedure for combining a setting (20001) and the logging instruction (20002) into one system prompt, the block structure and order of that prompt, and the criteria for choosing a logging output format (inline, structured, tool call). What it does not define — what answers your AI should give. Apply is the procedure that carries a direction; it does not decide the direction (non-normative). It also does not prescribe a model, vendor, or deployment method.
Step 4 of the integrity loop — Apply
AIO 20001 · Set declares the direction, AIO 20002 — Reasoning Record Standard keeps the record, and AIO 20003 · Analyze finds the drift — Apply puts the result back into the system. This is where the loop closes, and the moment it closes it returns to step 1. Apply is not the terminus; it is the starting line of the next turn.
Agreements die in documents
Most AI governance stops at the document. A team spends half a day agreeing on a hierarchy, produces a well-written principles document, and not one line of it ever reaches the system that actually produces answers. Operations keep running on vendor defaults.
Apply is the deliberately practical step that closes that gap — instead of coding thousands of rules, it turns one agreed direction and one logging instruction into text you can paste. The point is that a small organization can complete its first turn of the loop today.
And because the logging instruction goes in with it, Apply carries its own verification. From the moment the prompt is in place, logs accumulate — and those logs are the input to the next analysis.
Six blocks of the combined system prompt
The combined prompt is not free-form text; it is a document with a fixed order. The first five blocks come from your setting, the last comes verbatim from the standard repository.
Identity and scope
Which organization and which domain (medical, education, public sector…) the setting applies to. The domain maps straight onto the context code in the log.
Value hierarchy
The priority order agreed in the workshop. Not what is right, but what comes first when two goods collide.
Red lines
Items that are never reversed. If the hierarchy is a flexible preference, a red line is a boundary that does not negotiate.
Situational exceptions
Situation red lines and value weights from the domain profile — what shifts by situation even inside one organization.
Policy under uncertainty
Whether to hold, escalate to a human, or answer conservatively when the call is genuinely close. Most incidents come from leaving this blank.
Logging instruction (AIO 20002)
The logging prompt verbatim from the standard repository. It makes the model leave one C/V/E/S line per decision — never shown to the end user.
The sixth block is used exactly as committed to the standard repository AIO20002 — the site never rewrites it. The commit hash records which version went in.
Three logging output formats
There is really only one choice to make in Apply — how the model should emit the log. All three formats carry the same C/V/E/S code, and in none of them is the log visible to the end user.
Inline tag
One <aio20002_log> line at the end of the response. Works in any chat interface — the lowest barrier to entry.
Trying it today
Structured output
Response and log split into JSON fields. Best when a pipeline has to parse and store them.
Wiring into a product
Tool call
The log is emitted through a record_aio20002_log tool call. Fully separated from the response body — the lowest leakage risk.
Standing up an audit trail
What you can do now, and what comes once logs accumulate
Setting + logging = one system prompt
Press ‘Start’ in the hero to (1) pick the setting to apply, (2) choose the logging response format, then (3) take the combined system prompt as .md or copy it to the clipboard. Sign in and your saved 20001 projects appear in the list.
No setting yet? The AIO 20001 workshop takes 30 minutes.
Check alignment → risk check → improved prompt
Once logs accumulate, we check whether the setting matches the actual logged results, run an additional benchmark (20003) to inspect risk signals, fold those into finer settings, and hand back an improved single system prompt.
The standard document is in preparation through the public RFC process.
What this step does NOT claim
- Putting the prompt in does not guarantee the model follows the direction. Verifying that it does is the job of Log (20002) and Analyze (20003) — Apply only means something with those two in place.
- A system prompt is not a safety mechanism. It does not replace guardrails, filters, or human review; it adds a direction on top of them.
- The log the model leaves is a self-report. It is not a causal trace of internal computation, but a record of what the model reports it prioritised.
- The Apply standard document (20004) is not final. What is offered today is a stage-1 implementation of the procedure, to be finalised through the public RFC.
First, find out how much is standing
Five questions — yes / partially / no. Each ‘no’ points at which step of the loop is empty. Two minutes, and nothing is stored.
Building the application cases together
The Apply step becomes a standard only as real organizational cases accumulate. Which block was missing in your domain, which output format was realistic in practice — that experience is the content of the 20004 RFC. Joining as an application case feeds directly into how the combining procedure improves.