The Helmark Standard

STD 1.0

0.0 The standard in five sentences

1. Every task gets a label: NONE / ASSIST / CORE — how much AI was in it.
2. More AI = more verification. CORE requires a prompt description, a test and a genuine review.
3. A human is always accountable. Never a tool.
4. Understanding of the code is measured: a named Anchor per component, a recurring Signal.
5. Adoption takes one week. Any process, any tracker, no new tools.

INTRODUCTORY PART

0.1 About the standard and its scope

Helmark is a standard for staying in control of AI-assisted software development, built for delivery teams. It defines how a team classifies AI involvement in its work, how it verifies that work, and how it protects its own understanding of the system. The standard is free and open; training, certificates and audits are paid.

It works with any way of working and any tracker — it defines no process roles, no meetings and no planning method.

The standard does not cover: the choice of AI tools or prompt-writing techniques, data security and legal matters, or measuring people's productivity.

0.2 Glossary

0.3 The founding rule

One rule applies throughout the standard and takes precedence over every other provision:

A production problem is answered for by the human who introduced the change. Not the model, not the prompt, not the vendor. A team that says "the model got it wrong" makes verification optional — and within a few weeks stops verifying at all.

PART I — CLASSIFICATION

1.1 Three levels of AI involvement

Every task must carry exactly one classification. The task owner sets it before review.

The levels carry no judgement. CORE is not worse than NONE. The standard requires only an honest label — because the label determines how much verification is due.

1.2 Classification rules

• The task owner sets the classification, before review.
• The classification field must have no default value — the choice must be conscious.
• The tie-breaker rule: if you removed the AI's contribution, would recognisable human work remain? If only an empty file or a prompt remains — it is CORE.
• When in doubt, classify up. The cost of extra verification is minutes; the cost of under-classifying is an incident in code nobody understands.

Under-classification (labelling CORE as ASSIST to dodge the requirements) is the most common failure of the standard. A team with no CORE tasks at all is almost certainly under-classifying.

Borderline examples:

1.3 Agent work

The result of an agent's work is CORE by definition — no matter how good it looks.

Every task performed by an agent must have a human owner, appointed before the agent starts work. The owner answers for the agent's result as for their own (R1).

The CORE label on an agent's task must be set no later than the moment the agent starts — manually or automatically (1.4).

1.4 Sources of classification

The classification may come from three sources:

• Manual — the owner sets the label. The default; works everywhere.
• Automatic — an attribution tool or commit metadata proposes the label based on the share of generated code.
• Hybrid — the tool proposes, the human confirms. Recommended wherever tooling exists.

The overriding rule: a tool may set the label — it may never satisfy the verification. The prompt description, the test, the review and the accountability are always human (R1).

A team using automation must agree a mapping once and write it down (e.g. more than half of changed lines generated → a CORE candidate; any generated lines → at least ASSIST).

PART II — VERIFICATION

2.1 Requirements per level

The ASSIST note takes 20 seconds and tells the reader where to look. The second person at ASSIST need not be a formal reviewer — anyone on the team who confirms the note is enough.

2.2 The prompt description

The prompt description must make it possible to compare the order with the delivery — even months later, without the author in the room. Minimum content: what was ordered, what constraints were given, what was accepted from the result unchanged.

It is an auditable artefact. It is recorded in the task or in the change description — no separate tools.

2.3 Reviewing CORE changes

The idea is simple: the author of the code is an AI, so it cannot be asked about its intentions. The reviewer cannot rely on a conversation with the author — they must rely on artefacts.

So the reviewer checks two things: whether the result matches the prompt description (delivery = order) and whether the test or scenario actually checks the goal of the change.

How to organise this — the team works out for itself. The standard requires only that the review be real, not an automatic sign-off.

PART III — PROTECTING UNDERSTANDING

AI generates code faster than people build understanding. Part III protects understanding as an asset — measured, not wished for.

3.1 Cognitive debt

Cognitive debt is code that works, but that nobody on the team can explain.

It is not technical debt. Technical debt slows change down; cognitive debt makes change dangerous — you edit code without knowing what it touches. The worst case: clean, tested, generated code that is foreign to everyone. No classic metric can see it.

3.2 The Anchor (Knowledge Anchor)

Every significant component should have an Anchor: one person who can explain how it works.

The Anchor is not automatically the author — the Anchor is the person who can teach (they may be the author, but need not be). The test: can they explain the component to a new team member in 15 minutes, without opening the code? If nobody passes — the component has no Anchor, whatever the spreadsheet says.

The team must maintain a list of components. Each component is assigned an Anchor if such a person exists; gaps on the list are allowed — but they must be visible. Gaps are data, not shame.

3.3 The Handover

On finishing their last open task on a given component (that is, leaving it for other work), the developer leaves one sentence in their own words: what this code does and where the risk is. As a code comment or in the task.

One sentence can be enforced — documentation cannot. Writing it is a test: if you cannot summarise the code in your own words, you have just discovered that you do not understand it. "Pasted what the model generated, works" — does not pass. "We cache sessions for 24h; risk: a timezone change can duplicate the key" — passes.

3.4 The Focus Block

Understanding requires uninterrupted thought.

The team must establish a Focus Block: protected time with no meetings and no expectation of answering messages — for every person. The frequency and length are set by the team to fit its own circumstances, and written down as a rule. Once set, the rule is binding; it changes only by a conscious team decision, never by a quiet exception.

Without protected time, Anchors exist only on paper and Handover sentences are empty — nobody physically had the time to build the understanding.

3.5 The Signal (Cognitive Debt Signal)

The team must check on a recurring basis how many components have an Anchor and how many are orphaned — and monitor the trend: is the number of orphaned components growing or shrinking?

For every orphaned component, the team decides who will build understanding of it, and by when.

The frequency of the check is set by the team and written down as a rule. One number, counted on fingers — enough to turn understanding from a wish into a tracked asset.

PART IV — ADOPTION AND COMPLIANCE

4.1 Adoption in one week

4.2 Tooling requirements — exactly three

1. A field or label for the classification.
2. A place for text (the note, the prompt description, the Handover) — a task comment is enough.
3. A filter for CORE tasks — so the mandatory review can be enforced.

Nothing more. No plugins, no new tools.

4.3 Maturity levels

The levels are cumulative.

4.4 The audit checklist

A "yes" must be backed by an artefact (a task, a change record, a calendar) — never a declaration.

1. Does every task closed in the last 2 weeks carry a classification?
2. Have any CORE tasks occurred in the last month? (zero = probable under-classification)
3. Does a random ASSIST task carry a note and a second confirming person?
4. Does a random CORE task carry a prompt description comparable with the result, and a test or a scenario record?
5. Does review history show genuine CORE review, not an automatic sign-off?
6. Does a current list of components with Anchors exist (gaps visible)?
7. Can a random Anchor explain their component in 15 minutes without opening the code?
8. Did the last three departures from a component produce Handover sentences?
9. Is the Focus Block rule written down, are the blocks in calendars — and were they recently respected?
10. Is the Signal checked according to the written rule — and does the team know the current trend of orphaned components?

Questions 2, 5 and 7 are deliberately the hardest to fake — they separate adoption from theatre.

FINAL PART

5.1 Formalities

Versioning. Numbering: STD MAJOR.MINOR; a MINOR change clarifies, a MAJOR change may alter requirements. A team citing the standard states the version (e.g. "Helmark STD 1.0"). Change proposals: the form at helmark.org; the decision rests with the authors.

Name and mark. Anyone may adopt the standard free of charge and cite it. The name "Helmark Certified", the titles HDP/HDL/HCR/HCT and the graphic mark may be used only by holders of certificates and licences issued by Helmark. Modified versions of this document may not be published under the Helmark name.

Authorship and licence. Authors: Piotr Sobiegała & Mateusz Pluta. The standard is published free of charge at helmark.org. Licence: [ CC BY-ND 4.0: quoting with attribution yes, modified versions no].

APPENDIX A — The standard in practice (cheat sheet)

The Helmark Standard STD 1.0 · helmark.org