01 / THE METHOD
Each step establishes the basis for the next.
IMPACTS began with five First Principles steps for physical production. Removing, ordering and accelerating work is insufficient for agentic and knowledge work: each retained contribution needs a checkable basis for decisions at the point of work. Human interactions, variants and approvals belong in the initial diagnosis.
Read the original method ↗- I
01 / Identify
Understand the work.
Which outcome matters? Where does work stall? Which decisions and customer interactions stay with people?
- M
02 / Minimize
Remove unnecessary work.
Question handoffs, waiting and duplicate capture. Keep what contributes to the outcome.
- P
03 / Perfect
Make the process verifiable.
Define inputs, outputs, a verification rule and complete onward routes for every step.
- A
04 / Augment
Supply context at the point of work.
The minimum sufficient, current and checkable context is routed from its source to the human, agent or system in time, or derived traceably. Frequency, complexity and source state determine whether this needs a file, direct read or maintained knowledge service. Missing context stays open.
- C
05 / Construct
Write the target process.
The Application describes the reusable process in readable files: with instructions, an entry point and routes.
- T
06 / Test
Test against real requirements.
Compare representative runs with a baseline: check the outcome, guardrails, throughput and failure cases.
- S
07 / Scale
Reuse the tested revision.
New runs use the tested Application revision. Existing runs remain bound to their historical revision.
02 / THE PUBLIC CORE
A readable contract for the process.
The published core defines the file structure and validates its rules. A separate agent harness executes the work; capabilities provide tools and deterministic calculations.
- Application
- One main process with an embedded result contract: outcome, metric and acceptance criteria.
- Process step
- Inputs, outputs, verification and routes sit alongside the work instructions.
- Run
- A concrete run binds to an Application revision. Its path records the steps reached.
- Human approval
- A human gate has approval and rejection routes. The decision is recorded in the run.
A valid structure demonstrates conformity with the file contract. Domain quality and usefulness must be tested against the actual process.
Our own development · a documented decision
A valid file is not yet a good result.
The public IMPACTS Core separates structural validation from execution. The core checks process files. A separate harness executes the steps; domain results need their own review.
Why this boundary matters: a rule can check whether an approval and its onward routes are recorded. That alone cannot establish whether a proposal is correct or a decision is sound.
The concrete work object
The published specification shows a step with human approval. Both decisions have an explicit onward route:
gate: human
routen:
freigegeben: arbeitsschritt:befund-erfassen
abgelehnt: end:unterlagen-unvollstaendig
The chosen boundary
Validation reads the contract without executing the process or changing files. Tools and calculations remain outside the core. This makes the structure inspectable before an execution system acts. Adding execution to the core is explicitly outside this published scope.
What still needs checking in the result
A successful structural test replaces neither domain acceptance nor evidence of customer benefit. A concrete deployment still needs checks of result quality, permissions and the path actually executed. This example documents Aprixity's own protocol development; it does not report a measured customer project.
Original: Minimal IMPACTS Core V1 · Design dated 30 August 2026, pinned repository revision 1a0cf9c.
03 / SOURCES & SCOPE
Read the source. Check the scope.
This introduction summarises the public repository revision. It describes the method and core; it does not establish customer outcomes or certification.
Melvinanalytics / impacts-protokoll
Source revision: 5ad90cd42b79