PUBLIC AI DELIVERY GOVERNANCE STANDARD · STD 2.0
AI writes code faster
than your team can
understand it.
Helmark gives engineering organisations a practical control layer for AI-assisted software delivery: see where AI materially contributed, apply verification proportional to AI involvement and software criticality, and keep a person accountable for every accepted change.
Public standard · Tool-agnostic · No dedicated platform required · Works with your existing SDLC
THE MANAGEMENT GAP
AI adoption is easy to start. Control is harder to prove.
Once AI becomes part of everyday development, engineering leaders need consistent answers to questions that normal delivery tooling does not always capture.
How much human verification was appropriate for the AI involvement and the risk?
Who knowingly accepted the result?
Can the team still independently understand and verify the system?
R1 / FOUNDING RULE
Responsibility for a change cannot be delegated to AI.
AI can generate, analyse, test and review. Helmark keeps the acceptance of a software change with a human owner.
WHAT HELMARK CHANGES FOR YOU
One standard. Different value for each part of engineering.
Helmark is a public standard, not a replacement for your delivery process. It provides shared delivery-governance rules for organisations that already use AI in software delivery.
Know where AI is entering your software — and where stronger control is justified.
Get a consistent organisation-wide language for AI involvement, component criticality and human acceptance without replacing the delivery process teams already use.
Management benefit: visibility and accountability across teams.Give teams one shared control model instead of ad hoc AI rules in every repository.
Use the same classification and minimum verification logic across teams, with stronger controls for CORE work and for ASSIST / CORE changes in HIGH and CRITICAL components.
Operational benefit: more consistent decisions with less ambiguity.Use AI without turning every AI-assisted change into a compliance exercise.
Low-risk ASSIST work stays lightweight. Human review is required for CORE work and for ASSIST work in HIGH or CRITICAL components.
Practitioner benefit: proportionate rules instead of blanket restrictions.Move from “we use AI responsibly” to evidence that delivery controls actually happened.
Where required by STD 2.0, Helmark creates findable artefacts around AI involvement, intent, review and acceptance, while security, privacy, legal and enterprise AI risk requirements remain in their existing governance systems.
Governance benefit: delivery-level evidence without pretending to replace broader AI governance.WHAT YOU CAN ANSWER AFTER ADOPTION
Make AI-assisted delivery visible enough to manage.
Was AI involved?
Every in-scope task carries a NONE / ASSIST / CORE classification, except a narrowly defined written class of trivial changes.
How critical is the software?
Significant components receive a default LOW / HIGH / CRITICAL level, and tasks inherit it where a mapping exists.
What verification was required?
For ASSIST and CORE work, AI involvement and criticality determine the minimum Helmark verification. For NONE, the team’s normal process applies.
Who accepted the result?
A human owner remains responsible for knowingly accepting the change.
THE CONTROL MODEL
Two dimensions. One minimum verification requirement.
Helmark separates how the result was produced from how risky the affected software is.
AI INVOLVEMENT
NONE / ASSIST / CORE
Record whether AI played no part, supported a human-led solution, or produced the main result. Agent output is CORE by definition.
NONEASSISTCORE
COMPONENT CRITICALITY
LOW / HIGH / CRITICAL
Criticality is primarily a property of the component. A task inherits that level and may be raised when the specific change carries greater risk.
LOWHIGHCRITICAL
PROPORTIONAL, NOT MAXIMAL
Helmark does not treat every use of AI as high risk.
That distinction matters if you want governance that teams will actually use.
ASSISTLOW
For ASSIST / LOW work, the owner records where AI was used and how the result was checked.
No second person is required merely because AI was used.ONE CONCRETE EXAMPLE
An agent produces most of a change to a critical payment component.
Helmark does not prohibit the agent. It raises the human verification required before acceptance.
AI INVOLVEMENTCORE
+
COMPONENTCRITICAL
=
MINIMUM CONTROL
Intent + test/scenario + human review + component-specific risk assessment + independent human verification criterion
THE SECOND PROBLEM: UNDERSTANDING
Working software is not enough if nobody can independently explain it.
As adoption matures, Helmark treats software understanding as an asset that can grow, decay, be transferred and be rebuilt.
Cognitive debt
Code works, but the team does not understand its behaviour and consequences well enough to maintain it safely.
Knowledge Anchors
Make visible which people can genuinely explain significant components — and where knowledge gaps exist.
Intervention boundary
Identify components where the team can no longer independently judge whether an AI-proposed solution is correct.
WHERE HELMARK FITS
Keep your existing SDLC. Add a delivery-governance layer for AI.
Helmark does not replace security, privacy, legal requirements or enterprise AI risk management.
ORGANISATIONAL GOVERNANCE
AI risk · security · privacy · legal requirements
↓
HELMARK STD 2.0
AI Delivery Governance
Classification · proportional verification · human ownership · protection of understanding
↓
YOUR EXISTING DELIVERY SYSTEM
GitHub · GitLab · Jira · Scrum · Kanban · PR-centric workflows
ADOPTION
Start with control. Add maturity when the organisation is ready.
Helmark STD 2.0 deliberately defines an order of adoption instead of imposing a fixed timeline.
Make AI involvement and verification visible
Classification works, significant components have a default criticality, tasks inherit it where mapped, R1 is known and minimum verification is performed.
Make the rules enforceable
Required artefacts exist, human review really happens and HIGH / CRITICAL controls are checked on samples.
Protect the organisation's understanding
Anchors, the Cognitive Debt Signal, handovers and the intervention boundary make knowledge risk visible.
A REALISTIC FIRST STEP
Start with one team or one product area.
Add NONE / ASSIST / CORE. Map significant components to LOW / HIGH / CRITICAL. Turn on the minimum verification rules. Then sample real changes and correct ambiguities.
EARLY REAL-WORLD ADOPTION
Helmark is being implemented at Speaklay.
A 15-developer software team is applying Helmark in a real delivery environment. The case study focuses on implementation structure; outcome claims will be added only after validation.
View early adoption →THE STANDARD COMES FIRST
Read and use Helmark STD 2.0 without buying training.
The standard is public and free to adopt. Training and certification exist to support practitioners and organisations that want structured learning or formal recognition — they are not a condition of use.
CERTIFICATION BADGES
Training can end with a visible Helmark credential.
HDP supports practitioners. HDL supports leaders implementing Helmark across teams. Both paths can end with an official Helmark certification badge.
See training and badges →
HDP
Practitioner-level certification.
HDL
Leadership-level certification.
HELMARK STD 2.0
Use more AI.
Lose less control.
Make AI involvement visible, verification proportional and human acceptance explicit.