Strict tier

Audit-ready, capability-declared, signed, and verifiable. The tier for regulated industries, platform teams, and anyone whose AI-assisted code needs to survive compliance review.

Audience #

Pick Strict if any of these describe you:

You work in finance, healthcare, defence-adjacent, or any regulated industry where AI-generated code must be traceable.
Your organisation has internal policy mandating provenance on AI-assisted contributions (a fast-growing category as of 2026).
You're a platform / security team that wants to enforce, not just recommend, agent behaviour across many repos.
You expect to need SOC2 evidence, ISO 27001 alignment, or EU AI Act Article 12 logging on AI-assisted parts of your codebase.

If none of those describe you, Strict is overkill — pick Standard and upgrade if you ever need to.

Install #

npx aidokit init --tier strict

Or via the interactive picker; choose "Strict" when prompted.

What you get (beyond Standard) #

Component	Strict
Capability declarations	Adapter manifests declare every shell command, write path, and network host they use. Verified at install and on every sync.
Verified-not-just-declared	`aidokit` runs a static analysis pass; declared capabilities must match what the emitted hooks actually do. CI gate available.
Signed manifest	The `.aidokit/manifest.json` is content-addressed and signed; `aidokit verify` confirms install integrity.
Signed npm packages	All `@aidokit/*` packages ship with npm provenance / Sigstore attestations.
Audit export	`aidokit audit export --format soc2` and `--format eu-ai-act` produce evidence packets mapped to control numbers.
Stricter watchdogs	Out-of-scope writes are blocked AND logged to the metrics JSONL; deletion guard requires explicit task-brief grant.
Required artefacts	Every task must produce a change summary; every architectural decision must produce an ADR.
Conformance verification	`aidokit doctor --strict` is required to pass before any release tag.

(Everything from Standard is inherited unchanged.)

What you commit to #

Strict isn't free. In exchange for the audit posture, you accept:

Higher artifact discipline. Every task brief, every change summary, every ADR must be present and valid. The watchdog enforces this; you cannot skip a change summary by editing the file directly.
More vocabulary surface. Capability declarations, conformance harness, signed manifest, audit export — all real concepts the team needs to understand.
Slower velocity in exchange for traceability. Strict ships fewer tasks per week than Standard does. That is usually the right trade-off for regulated work.
Maintenance you commit to. ADRs go stale; the conformance harness reports them. Capability declarations need updating when adapters change. Strict is not "set and forget."

Audit posture today (honest) #

Question	Answer in 2026
Does Strict produce evidence sufficient for SOC2 CC-series controls?	The artifacts are the right shape; the mapping doc (`docs/compliance/soc2.md`) is being reviewed by external auditors. As of this writing, treat the export as a starting point for evidence, not a complete one.
EU AI Act Article 12 (logging for high-risk systems)?	The watchdog + metrics log capture the events the article requires. Mapping doc (`docs/compliance/eu-ai-act.md`) is in draft.
Will a Big Four auditor accept the output unmodified?	No. Plan for an internal reviewer to map our artifacts to your control framework. We minimise that work — we don't eliminate it.
ISO 27001 alignment?	The change-summary + ADR + capability declaration triad covers most of the relevant controls. Specific mapping is roadmap.

Coming from Standard? #

aidokit sync --tier strict --dry-run    # large diff expected
aidokit sync --tier strict

The upgrade adds capability declarations to your adapter manifest, turns on stricter watchdog modes, and writes a fresh signed manifest. Existing change summaries, ADRs, and Beads data are preserved.

After the upgrade, run:

aidokit doctor --strict

to surface any gaps the previous Standard install left behind.

Coming from Starter? #

Skip Standard — aidokit sync --tier strict works from Starter too — but be aware you'll see a larger diff and a steeper onboarding curve. Most teams find it easier to spend a few weeks on Standard first to get familiar with the role vocabulary before adding the audit layer.

Honest limitations of Strict #

The signed-manifest tooling is local-only. A central verification service would help cross-team trust; not yet shipped.
Capability verification is static. Runtime capability enforcement (a sandbox-style execution layer) is researched but not promised.
No multi-org policy distribution. Each repo declares its own capabilities; centralised policy across N repos requires external tooling today.
Audit export needs an auditor, still. The point of compliance artifacts is to make the auditor's job tractable, not to replace them.