DevHeal Research / DH-ADOM

Contracts that make ownership explicit.

The normative specification defines roles, delegation boundaries, lifecycle integration, evidence and conformance requirements.

White paper 1.1 · Publication package 1.1.1 · 7 October 2026

DH-ADOM Technical Specification v1.0

Status: Normative

Version: 1.0.0

Date: 2026-10-06

1. Scope

DH-ADOM specifies a repository-level operating model for AI-native software engineering. It defines governance hierarchy, agent roles, domain ownership, bounded delegation, lifecycle integration, evidence, state, handoff, and conformance requirements.

2. Normative language

The terms MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, and RECOMMENDED are normative.

3. Governance hierarchy

1. Engineering Constitution

2. AI-SDLC

3. ADLC

4. Root Agent

5. Feature Agent

6. Specialist Agent

7. Implementation

4. Agent roles

4.1 Root Agent

The Root Agent MUST own global orchestration and MUST NOT require itself to implement every feature.

4.2 Feature Agent

Every meaningful bounded domain SHOULD have one persistent Feature Agent. A Feature Agent MUST declare intent, ownership, capabilities, tools, permissions, autonomy, risks, state, and handoff.

4.3 Specialist Agent

A Specialist Agent MUST be created under a parent Feature Agent or explicitly authorized Root Agent. It MUST have a bounded purpose and task-scoped permissions.

5. Delegation Contract

Every delegation MUST identify parent, child, purpose, task, scope, permissions, budget, lifetime, evidence requirements, and acceptance criteria.

6. Delegation invariants

  • Child scope MUST be a subset of authorized parent scope unless explicitly widened through governance.
  • Delegation depth MUST be bounded.
  • Parallel child execution MUST be bounded.
  • Child permissions MUST NOT exceed delegated authority.
  • Completion MUST return evidence and handoff.
  • Uncontrolled recursive spawning MUST be blocked.

7. Feature ownership

Feature Agent ownership is an engineering boundary. Cross-feature changes require coordination through the Root Agent and MUST be traceable.

8. Identity and contract

Agent identity is distinct from model identity. Each agent MUST have an identity record and SHOULD have a machine-readable passport and contract.

9. AI-SDLC integration

All material work MUST map to intent, requirements, architecture, implementation, validation, evidence, release, and feedback.

10. ADLC integration

All agents MUST follow an agent lifecycle that includes intent, contract, identity, capabilities, permissions, autonomy, validation, promotion, monitoring, revalidation, and retirement.

11. Evidence

Meaningful tasks MUST emit auditable evidence of implementation and validation.

12. Handoff

A completed task MUST update state and create a machine-readable handoff sufficient for an independent AI session to continue work.

13. Security

Agents MUST follow least privilege. Production actions MUST be policy-controlled. Permission or autonomy escalation MUST NOT be self-authorized.

14. Conformance

An implementation conforms to DH-ADOM v1.0 only when all mandatory requirements in CONFORMANCE-REQUIREMENTS.md pass or have a formally accepted exception.

DH-ADOM v1.0 Conformance Requirements

An implementation MUST satisfy all CRITICAL requirements and provide evidence for each requirement.

IDRequirementClass
CR-001Engineering Constitution exists and is authoritativeCritical
CR-002Root Agent exists and is identifiableCritical
CR-003Feature Agent ownership exists for meaningful domainsCritical
CR-004Specialist delegation is boundedCritical
CR-005Delegation contracts are auditableCritical
CR-006Root does not silently bypass Feature Agent ownershipCritical
CR-007AI-SDLC state is representedHigh
CR-008ADLC state is represented for agentsHigh
CR-009Agent identity is separate from model identityHigh
CR-010Agent permissions are explicitCritical
CR-011Autonomy/delegation budgets are enforcedCritical
CR-012Agent creation is boundedCritical
CR-013State and handoff are persistedHigh
CR-014Requirement-to-evidence traceability existsHigh
CR-015Audit trail records delegation and material actionsHigh
CR-016Cross-feature changes are controlledCritical
CR-017Failure / timeout handling existsHigh
CR-018Fresh-session resumability is demonstratedHigh
CR-019No claimed completion without validation evidenceCritical
CR-020Conformance results are reproducibleHigh

Machine-readable definitions

The publication ZIP includes four JSON schemas, three lifecycle state machines and an OpenAPI interface outline. The outline describes intended interfaces; the package does not provide an HTTP service.

Get the specification and schemas →

Adoption glossary · informative.

These operational interpretations help adopters make the specification testable. They are guidance, not amendments to the version 1.0 normative text.

Bounded engineering domain
A registered ownership area with explicit repository paths or resources and a named owner.
Material work or meaningful task
Work that changes behavior, repository artifacts, permissions or externally observable state; define local thresholds in governance.
Production action
An operation affecting a live environment, user data or an external system beyond an isolated evaluation.
Explicit authorization
A traceable approval bound to an identity, task, scope, policy version and validity period.
Accepted exception
A documented deviation with rationale, owner, approval, scope and expiry; report it alongside assessment results.

Review conformance evidence →

Diagram

100%