The ACDD Pipeline
Most engineering teams using AI agents have no formal connection between what a product owner specifies and what the agent actually builds. Requirements deteriorate across handoffs, prompts drift from intent, and by the time a build closes there is no reliable way to prove the output matched the original instruction.
CountABILITY's Agentic Compliance-Driven Development (ACDD) pipeline closes that gap. Every requirement becomes a governed prompt handoff. Every stage is checkpointed. When the build closes, CountABILITY scores delivery against the original acceptance criteria and writes the evidence to a tamper-evident chain — giving product owners verifiable proof the agent built exactly what it was asked to build.
/brainstorm & /intake
Collaborative requirement discovery. Raw ideas and transcriptions are structured into governed inputs before any spec work begins.
/spec — Specification
Requirements are formalized with EARS normalization — structured syntax enforced at the sentence level. Priority extraction and obligation strength verified before the spec is sealed.
/review-spec — Adversarial Review
Minimum two adversarial review passes against the spec. Ambiguity, scope drift, and missing acceptance criteria surfaced before build begins.
/plan & /review-plan — Implementation Plan
Implementation plan derived from the spec, reviewed and locked before a single line of code is written.
/draft & /review-prompt — Governed Prompt
The build prompt is generated from the spec and plan, reviewed for completeness against the 6-section prompt standard, then locked. The agent receives a governed prompt — not an improvised instruction.
/build — Per-AC Governed Loop
The agent executes acceptance criteria one by one. Each AC transition is checkpointed, token spend is gated, and every action is written to the audit chain in real time.
/complete — Scored Closure
Build closes with a 7-dimension audit report — spec fidelity, security posture, code quality, test coverage, AC quality, obligation strength, and token attribution. Evidence written to the tamper-evident chain.
/refine — Governed Refinement
Spec changes after build start are tracked, reviewed, and chained. Refinement decisions are first-class audit events — not invisible edits.
EARS Normalization
Requirements are auto-normalized to structured EARS syntax before entering the pipeline — eliminating ambiguity at the source.
Obligation Strength Verification
"Shall," "should," and "may" are enforced against tier policy. Weak obligations are flagged before build — not discovered in audit.
Token Spend Gate
Each AC transition requires a minimum token spend threshold before advancing. Agents cannot paper over ACs with zero-work checkpoints.
Coupled AC Range Declaration
Inherently coupled acceptance criteria are declared at build start and logged to the chain — not silently skipped. Every row in the attribution table is honest.
Sprint Method Mandate
Sequential, combined, and auto sprint modes with four-layer precedence (spec → per-build → project → framework). Enforced, not advisory.
Checkpoint Governance Gate
AC transition checkpoints are validated by the validate_build_governance MCP tool. Missing checkpoints block build closure.
The Tamper-Evident Audit Chain
Every governed build is scored across 7 quality dimensions — spec fidelity, security posture, test coverage, token burn, and more — as a direct output of the ACDD prompt chain. Every session, tool call, and commit is written to a SHA-256 hash chain: immutable, tamper-evident, and exportable. Security scans, validation gates, and requirement traces are attached as first-class evidence — ready before the auditor asks.
This is not a reporting layer on top of git history. The audit chain is written in real time during the build, cryptographically linked at every step, and scored by CountABILITY's own engine — not reconstructed after the fact. For regulated industries operating under IEC 62304, ISO 13485, SOC 2, or 21 CFR Part 11, this is the evidence package your auditors require, generated automatically on every build.
SHA-256 Hash Chain
Every audit event is cryptographically linked to the prior event. A single tampered entry breaks the chain — detectable immediately.
7-Dimension Build Scoring
Spec fidelity, security posture, code quality, test coverage, AC quality, obligation strength, and token attribution — all scored at build close.
Delivery Confidence Composite
3-signal weighted composite score with 4 industry profiles. Uniform critical floor of 49. Deterministic recommendation engine — no subjective interpretation.
Per-Requirement Token Attribution
Token burn is tracked per session, per AC, and per phase. Every row in the attribution table represents a real token-spend window — verifiable by construction.
Chain Anchor Fields
First hash, last hash, and entry count are injected into every build closure and rendered across all evidence adapters — Linear, Confluence, ADO, Markdown, Plain Text.
Stub Anchor Detection
Fake or stub audit chain anchors are detected at seal time and rejected. Audit files cannot be closed against a non-real chain.
Cross-Linked Session & Token Fields
Every audit chain entry is cross-linked to the constraint token session that produced it. Session → build → requirement → token burn — the full chain of custody is literal.
Exportable Evidence Package
Full audit report exportable as structured JSON. Security scans, validation gates, fidelity scores, and requirement traces included as first-class fields — not appended footnotes.
Policy Enforcement
Agent governance that only advises is not governance — it is documentation. CountABILITY's policy layer is declarative, version-controlled, and enforced at execution time. What agents can and cannot do is defined in a single behaviors.yaml file that lives alongside your code, ships with your repo, and is read by CountABILITY's enforcement engine before any agent action executes.
Policies cascade from org level to project level to individual build. Guardrails ship with safe defaults out of the box — no configuration required to be protected on day one. Teams that need custom policies modify one YAML file and commit it. There is no dashboard to configure, no cloud policy store to maintain, no vendor dependency for enforcement to work.
behaviors.yaml — Single Policy File
One human-readable YAML file governs every agent session. Version-controlled alongside your code. No external policy store required.
Safe Defaults Out of the Box
6 default blocked bash patterns ship with every install. Teams are protected immediately — before they've written a single custom policy rule.
Deployment Gate
5-gate evaluator — health, coverage, drift, open scans, and CVE — must pass before any deployment proceeds. Defined in behaviors.yaml, enforced in CI.
Build Governance Stanza
Per-build token spend minimums, AC checkpoint requirements, and sprint method mandates all configurable in behaviors.yaml — not hardcoded in tooling.
Security Gate Stanza
Specification-derived severity policy. Scan thresholds, CVE severity gates, and scan-fail behavior are all defined in policy — not buried in CI configuration.
Session Lifecycle Policy
Session start, pause, resume, and close are governed events. Expired sessions fail closed — agent execution halts, not warns.
OS-Level Agent Security
CountABILITY's enforcement hooks operate below the agent — before the database command runs, before the email sends, before the file is deleted. The agent cannot see them, cannot reason around them, cannot self-authorize past them. Not a policy suggestion. A hard stop.
Setup is a single command. countability init installs and wires every hook automatically. What agents can and cannot do is defined in plain YAML — one file, human-readable, version-controlled alongside your code. Works out of the box across every MCP-compatible agent tool — Claude Code, Cursor, Windsurf, Augment, Rovo Dev — with no platform-specific configuration required.
Pre-Execution File Write Interception
Every write is blocked, evaluated against policy, and logged before it touches disk. The agent never gets to decide what is safe to write.
Test File Protection (Hook 6)
Agents cannot modify test files without an explicit session-scoped exception. Test suites cannot be silently overwritten to make failing builds pass.
Agent Cannot Self-Authorize (Hook 10)
Governance sentinels — .hook_exceptions, .session_ready, .session_paused — are OS-protected. An agent cannot grant itself permission to bypass enforcement.
Stub Anchor Rejection (Hook 11)
Fake audit chain anchors are detected at seal time. An agent cannot close an audit file against a non-real chain — governance evidence cannot be fabricated.
Fail-Closed Session Expiry
When a session expires, agent execution halts. There is no grace period during which an expired session can continue acting. Fail-closed, not fail-warn.
Session-Scoped Exception Model
countability hook allow grants time-bounded, pattern-matched exceptions logged to the chain. Exceptions are auditable decisions — not invisible bypasses.
Blocked Bash Patterns
Dangerous shell patterns — destructive filesystem operations, production database commands, mass communication triggers — are blocked at the OS layer before execution.
No Agent Cooperation Required
Enforcement is invisible to the agent. Hooks run at the OS layer — the agent process has no visibility into them and no mechanism to disable or circumvent them.
Security & CVE Management
Security in agentic builds is not a post-deployment concern — it is a build-time governance requirement. CountABILITY integrates security scanning directly into the governed build loop, writing every scan result to the audit chain as a first-class event. The four-phase closure model — scan, remediate, rescan, close — means every security finding has a cryptographically linked resolution record before the build is sealed.
Severity thresholds, scan failure behavior, and CVE gates are defined in behaviors.yaml — not buried in CI YAML or locked in a vendor dashboard. Your security policy travels with your repo.
Governed Post-Build Security Scan
Bandit, Semgrep CE, and pip-audit run with a unified FindingSchema. Every finding is normalized, deduplicated, and written to the chain — not siloed in separate tool outputs.
Four-Phase Scan Closure Loop
Scan → remediate → rescan → close. Each phase writes a chain event cross-referenced to the prior phase by hash. No finding can be marked resolved without a linked rescan record.
CI Security Gate
Bandit, pip-audit, Semgrep, and Gitleaks run as a parallel GitHub Actions job on every PR. Nightly CodeQL SARIF for deep static analysis. Builds do not merge with open critical findings.
SBOM Generation
CycloneDX and SPDX SBOMs generated via Syft on every build. Grype CRITICAL gate blocks deployment if new critical CVEs appear in the dependency tree.
NIST CSF Security Posture Scoring
9-control hybrid scoring model with 4 industry profiles and a uniform critical-control floor of 49. Two-step temporal decay reflects posture degradation over time.
Dependency Monitoring
Dependabot integration with weekly regression workflows. New CVEs surfaced automatically — not discovered in quarterly audits.
Custom Semgrep Rules
2 CountABILITY-specific Semgrep rules ship out of the box, targeting agentic build patterns that generic rulesets miss.
pip-audit OSV Fallback
pip-audit falls back to OSV database when PyPI advisory data is unavailable. No silent gaps in dependency vulnerability coverage.
Atlassian Integrations
Enterprise engineering teams don't abandon their existing toolchain when they adopt new infrastructure — they extend it. CountABILITY's Atlassian integrations are bidirectional and governance-aware. Requirements flow in from Confluence and Jira as pipeline inputs. Audit evidence, governance summaries, and test coverage flow back out — without manual copy-paste, without leaving the governed build loop.
All three integrations are MCP-native. They are invokable from within any governed build session and write their own chain events — every Jira transition, every Xray evidence submission, every Confluence publish is a first-class audit record.
Confluence
Bidirectional. Pull requirements in as pipeline source. Push governance evidence back as a structured summary page.
- Requirement source adapter — ingest pages directly into the ACDD pipeline
- Governance summary page — program-level evidence published automatically at build close
- Layer 3 evidence presentation — chain anchor fields rendered in the summary
- MCP tool: confluence_update_governance_summary
Jira
Full issue lifecycle from within the governed build loop. Create, read, comment, and transition issues without leaving the session.
- Create issues from governed build events
- Fetch issue state into local governance evidence
- Add comments and transition issue status
- CLI sync: countability jira sync
- MCP tools: create, get, comment, transition
Xray
Live GraphQL API integration. Submit test evidence, retrieve coverage, and update test runs directly from the audit chain.
- Add evidence to Xray test executions
- Retrieve test coverage per requirement
- Update test run status from build results
- Live GraphQL API — hardened for production use
- MCP tools: add_evidence, get_coverage, update_test_run
Cross-Platform Enforcement
CountABILITY governance does not belong to any single agent platform. The enforcement layer runs at the OS level — below the agent, independent of the client. The same policies, the same hooks, the same audit chain operate identically whether the agent is Claude Code, Cursor, Windsurf, Augment, or Rovo Dev. Switching platforms does not mean rebuilding governance. Adopting a new platform does not mean a governance gap.
Platform-specific plugin systems are never used as the enforcement path. Every capability installs via countability init, enforces via OS-level or git hooks, and runs on stdlib with no platform coupling. This is the architecture required for regulated industries where toolchain independence is a compliance requirement, not a preference.
countability init — One Command Install
Tier-aware installer auto-detects your platform and wires every hook. Up and running in under 5 minutes on any supported platform.
countability doctor
Health checks, hook validation, and platform manifest verification. Identifies misconfigured or missing enforcement components before a build starts.
platforms.yaml — Portability Manifest
The portability layer manifest declares which platforms are active, which hooks are wired, and what the enforcement state is for each — version-controlled and auditable.
Git-Native — Zero New Infrastructure
No cloud dependency. No proxy service. No vendor lock-in. CountABILITY runs on your existing toolchain — git hooks, stdlib Python, and your repo.
Platform-Agnostic Hook Architecture
Thin platform wrappers. Same Python validators underneath. Enforcement behavior is identical across every supported platform — no behavioral divergence by client.
countability sync
Reconciles local workflows and platform configuration against the CountABILITY framework baseline. Keeps governance state consistent as the framework evolves.
Code Quality
AI agents produce code at a rate no manual review process can match. Without automated quality enforcement, technical debt accumulates invisibly — D and F grade modules ship to production, complexity grows unchecked, and the codebase becomes unmaintainable faster than any previous development paradigm.
CountABILITY's code quality engine scores every module across 6 dimensions on every build and blocks D and F grade code in CI before it merges. Quality is not a periodic audit — it is a per-build gate, scored against the same standards, reported to the same audit chain, enforced by the same governance model as every other CountABILITY capability.
6-Dimension Per-Module Scoring
Cyclomatic complexity, maintainability index, test coverage, duplication, documentation density, and dependency coupling — scored per module on every build.
Sentrux Integration — Dimension 7
Architectural health scoring at the aggregate level via Sentrux sidecar. Structural debt surfaces as a scored dimension alongside the standard 6 — not as a separate tool output.
Quality CI Gate
GitHub Actions workflow blocks D and F grade code from merging. Quality enforcement runs in CI — not as a post-merge advisory dashboard.
Per-Module Drift Tracking
Quality scores are tracked over time per module. Drift — a module declining from B to D across builds — is surfaced as a chain event, not buried in a diff.
Code Quality Audit CLI
countability audit — run quality scoring locally at any point. Results written to the audit chain as a scored event with full module breakdown.
Quality Score in /complete
Code quality is one of the 7 dimensions in the build closure report. Every build closes with a quality score — not an optional add-on, a required evidence field.
Dashboard
Governance evidence is only valuable if it reaches the right stakeholders in the right format. CountABILITY's dashboard surfaces the audit chain, security posture, code quality, and delivery confidence across 6 purpose-built tabs — each designed for a different audience. Engineers see build state and coverage. Security teams see posture scores and CVE status. CISOs get a one-click exportable brief. Compliance reviewers get the full evidence package without requesting it.
The dashboard does not aggregate approximate data — every figure shown is derived directly from the audit chain. There is no gap between what happened and what is displayed.
6-Tab Architecture
Session state, audit trail, requirement coverage, security posture, code quality, and delivery confidence — each tab purpose-built for a distinct stakeholder.
Security Posture Tab
9-control NIST CSF grid with expandable panels per control. Industry profile selector. CISO brief export in HTML and JSON with one click.
CISO Brief Export
Exportable HTML and JSON security posture brief — formatted for executive review. Generated from live audit chain data, not manually assembled.
Delivery Confidence Tab
3-signal weighted composite with 4 industry profiles. Deterministic recommendation engine shows confidence level and the specific signals driving it.
Governance Summary — Confluence Publish
Program-level governance evidence page published directly to Confluence at build close. Stakeholders who live in Confluence get their evidence there — no portal login required.
Portfolio State Export
Full session and portfolio state exportable via export_portfolio_state(). Structured JSON — integrable with downstream reporting, BI tools, or compliance workflows.