A way to run software projects in which people and AI agents work from the same written decisions, link every change to the decision behind it and verify the result with evidence.
This page explains where project decisions and evidence belong, who may approve changes and how coding agents should use that information.
Software delivery becomes difficult to control when intent, requirements, constraints, design decisions, implementation work and evidence are scattered across conversations, people’s memory, work items, code and tools.
The risk grows when work moves between people and coding agents. An agent can act quickly, but it cannot follow a decision or constraint that it cannot find. People face the same problem when work moves between teams, contributors or sessions.
ADEL — the Agentic Delivery & Engineering Lifecycle — is a software delivery framework and way of working. Teams use it to keep people and coding agents aligned around the same approved decisions throughout delivery. Those decisions remain available for reference, changeable by the right approvers and traceable to implementation and evidence.
ADEL sorts project decisions into six layers. The project records each decision where people and agents can find it. When a decision changes, its approver updates the source of truth, and the team updates any later work that depended on it.
Seven lifecycle steps move work from the initial need to verification and closure. Work can return to an earlier decision when new information appears. The Agent execution overlay tells coding agents where to find each source of truth, which repository rules to follow, which required checks to run and how to report results.
ADEL has six framework layers and one Agent execution overlay. The layers separate different kinds of decisions. The overlay provides agent instructions across all six. Section 5 shows how work moves through the model in seven lifecycle steps.
Sets the rules every other layer must follow and names who may approve important decisions and exceptions.
Hold the requirements, design, plans, work items and evidence that take a change from the original need to a checked result.
Tells coding agents where to find that project knowledge and how to use it, within Governance and the permissions their tools enforce.
What project-wide rules must the work follow, and who may approve exceptions?
Defines project-wide principles, rules and decision authority that every layer and contributor must follow.
Tells coding agents how to work in the repository while following the project’s approved decisions and rules.
Governance holds the project-wide principles, rules and decision authority that every other layer must follow. The five delivery layers hold different project knowledge. Product Definition holds product intent and requirements. System Design holds the approved design and important design decisions. Delivery Planning splits approved work into clearly scoped work items and puts them in order. Execution carries out each work item. Assurance holds verification evidence and traceability. Work generally moves through these layers in that order. When new information changes a decision, return it to the responsible layer, update its source of truth and then update later work that depends on it. The Agent execution overlay works alongside all six layers. It tells coding agents where to find each source of truth, which repository rules to follow, which required checks to run and how to report results. ADEL defines these responsibilities, while each project chooses its own records, filenames and tools.
Each framework layer and the Agent execution overlay has one primary responsibility, expressed as a question. When several records claim to answer the same question, people and agents may not know which one to follow.
| ADEL layer or Agent execution overlay | Project knowledge carried | Question answered |
|---|---|---|
| Governance | Project principles and policy | What project-wide rules must the work follow, and who may approve exceptions? |
| Product Definition | Product intent and requirements | What must we build, for whom, and why? |
| System Design | Approved design and decision records | How will the system work, and why did we choose that design? |
| Delivery Planning | Delivery plan | Which work is ready, in what order, and who will do it? |
| Execution | Work item | What exactly is being changed, and how will we know it is done? |
| Assurance | Verification evidence and traceability | What evidence shows that the result works as required? |
| Agent execution overlay | Agent instructions | How should a coding agent work in this repository? |
ADEL is working when the people and agents making a change can answer these questions from current project records instead of reconstructing decisions from earlier conversations.
Why does this change exist, and what outcome or requirement does it serve?
What principles, requirements and design decisions constrain it?
Who may make or approve each important decision?
What clearly scoped work implements the current decision?
What evidence supports the conclusion that the result is acceptable?
ADEL defines which layer is responsible for each kind of decision and what each layer must keep on record. It does not prescribe every process, role, file or tool. The lists below show what ADEL is and what it is not.
A reusable framework for software projects delivered by people, AI agents or both.
Independent of any vendor; projects can use their existing editors, agents, repositories and technology stacks.
Adjustable to the project; the six layers stay the same while the amount of detail, record separation and change control can vary.
A claim that these example records or filenames are an industry standard. ADEL combines established requirements, architecture, decision-record and required-check practices with newer practices for instructing coding agents.
A waterfall process. Requirements and design can change; a project using ADEL records each change and links it to the work it affects, instead of letting it appear unannounced in the code.
A replacement for a complete organizational software development lifecycle (SDLC), security framework, compliance system, or operational and service-management process. Teams use ADEL to keep delivery decisions and evidence connected while those practices continue to govern their own areas.
Software teams often rely on information shared between people but never recorded where the project can keep using it. An architect may remember why a system boundary exists, a product owner may know which requirement matters most and a developer may know which checks must pass before a change is considered safe.
This problem becomes more visible when work passes to an AI agent. An agent can use only the information it can access, such as project documents, source code, repository instructions, work items and connected tools. If an important requirement, decision, constraint or working rule exists only in someone’s memory, the agent cannot reliably find or apply it.
ADEL assigns each kind of information to a responsible layer. The project records it where people and agents can access it and identifies the approver for important decisions. People and agents can then see what to change, why it matters, which rules apply and what evidence the work needs before it can close.
What can go wrong?
How would we notice it happening?
What does the framework provide to reduce the risk?
Important requirements, rules, design decisions or instructions are unavailable, scattered or locked in one conversation, person or tool.
Important requirements, constraints, reasons behind design choices or working conventions exist only in people’s memory. A new team member or AI agent therefore cannot reliably find them.
ADEL requires important project knowledge to be kept in records that future work can find: Governance principles, product intent and requirements, the approved design, decision records and agent instructions.
Every work item or AI prompt repeats large portions of project documentation because there is no clear way to find the sources of truth. Long prompts become difficult to maintain and may contradict one another.
Agent instructions list where each source of truth is kept, so each work item can link to the information it needs instead of repeating it.
Project knowledge becomes embedded in one AI agent’s prompt format, proprietary workflow or vendor-specific configuration, making it difficult to change tools or work without that agent.
Project knowledge stays in sources of truth that any tool can read, such as repository files or pages in the project’s tracker. Tool-specific instructions only tell each agent where those sources are; they do not become another source of truth.
Work continues without a clear connection to the intended outcome, project-wide rules or approved design.
Implementation follows the latest prompt rather than the approved design. Existing boundaries may be changed because the developer or agent cannot find why they exist.
Governance, System Design and its decision records write down the project’s rules, design boundaries and the reasons for design choices, so they do not depend on what one prompt says.
Working code no longer maps cleanly to the original business need, intended outcome or acceptance criteria. A feature may technically work while solving the wrong problem.
Product Definition and traceability connect the business need to requirements, design, implementation work and verification evidence.
A developer or agent introduces a new library, pattern, dependency, data flow or boundary as if it were only a local implementation detail.
Governance, System Design, decision records and conflict rules require an important architectural decision to be recorded and approved by its approver instead of appearing silently in code.
The delivered change cannot be traced to its purpose or supported by evidence that it meets the relevant requirements and acceptance criteria.
Work is reported as complete because code was produced, tests passed or the application builds, even though some requirements, constraints or acceptance criteria were never verified.
Verification checks the change against its requirements and acceptance criteria and keeps the evidence. Producing code, passing tests or building the application does not by itself complete the work.
Code exists but it is difficult to determine why it was introduced, which requirement it satisfies, which decision authorized it or how its correctness was verified.
Traceability connects the original need, requirements, design decisions, implementation and verification evidence.
Product Definition is responsible for the intended outcome and requirements. System Design and Execution are responsible for the design and implementation used to meet them. One record may contain both kinds of information when their responsibilities and approvers remain clear. If they are mixed without that distinction, people cannot tell where a change should be decided.
If two records describe the same decision differently, people and agents cannot tell which one to follow. A Product Definition record should not become an architecture document, and a work item should not silently redefine System Design. A summary may carry information needed for delivery, but it should identify its source of truth rather than become a second source for the same decision.
Keep important requirements, principles, decisions, constraints and evidence in project records that the people and agents doing the work can reach. Do not leave them only in chat history. Retain each record for as long as the project or its legal, contract or audit requirements demand. When a person or agent cannot access an external source of truth, provide an approved copy of only the information needed for the work and identify its source. Do not copy the entire project into every work item.
Agents can inspect, implement and run checks, but they must not silently change approved requirements, System Design or Governance decisions. ADEL states which decisions belong to the agent’s assigned work; organization policy, access controls and tool permissions enforce what the agent can actually do. A repository instruction cannot grant permissions the agent does not have, and content returned by an external source is information to evaluate, not automatically an instruction to follow.
Write down an architectural choice and its reason when it significantly affects system structure, portability, security, maintainability or long-term cost. Keep them in the approved design or a decision record. Use a separate decision record when future work needs the choice, alternatives, consequences or history—not for every implementation detail.
Do not treat work as complete because an agent says it is done. Check the acceptance criteria, run the required checks and keep the evidence. If a required check failed, was not performed or could not be performed, record that result. The work may close only if project policy allows an exception and the approver accepts it. Writing down a gap does not approve it, and rules that allow no exceptions still apply.
Traceability can be lightweight IDs, links and references. The goal is to answer why a change exists, not to create paperwork for its own sake.
Use all six layers in every project. Adjust how much detail you write, how many records you keep, how strict approvals are and how much evidence you keep to fit the work’s risk, complexity, contributors and legal, contract or audit requirements.
Section 3 describes the structure of ADEL: where different kinds of project decisions and knowledge belong. It does not define a fixed sequence of work; Section 5 describes the delivery lifecycle.
ADEL has six framework layers. Governance establishes the principles, decision authority and constraints that apply across delivery. The other five layers carry the decisions and project knowledge needed to move from Product Definition through Assurance. The Agent execution overlay is not a seventh layer; it provides agent instructions used across the framework.
These terms describe different parts of ADEL. A layer identifies the kind of decision it is responsible for. A lifecycle step describes what people and agents are doing at that point in the work.
| Term | Meaning |
|---|---|
| Layer | A continuing responsibility for a particular kind of project decision and knowledge. A layer is not a phase that is completed once. |
| Delivery lifecycle | The seven steps through which work is understood, defined, designed, prepared, implemented, verified and closed. A step may involve more than one layer. |
| Agent execution overlay | Agent instructions that tell coding agents how to find and use project knowledge while following decision authority and enforced permissions. |
A layer or the Agent execution overlay identifies the responsibility. Project knowledge is the information that responsibility must keep available. A record is the document, ticket, page or tool entry that keeps it. For example:
Use this overview to see what project knowledge each layer or the Agent execution overlay is responsible for, what it is for and when it is usually updated or retained. Open an item to read what it contains, what does not belong there and common ways to record it.
Governance principles keep the rules, constraints and decision authority that must remain consistent across features, contributors and agent sessions. Write them as clear statements that people can apply to decisions and, where practical, verify.
Use terms such as MUST, MUST NOT and SHOULD only when the project needs to show how strongly a rule applies. Examples include architectural independence, security and data rules, supported platforms, accessibility baselines, testing principles and decision authority.
If the principles are kept in a dedicated source, retain a history of significant changes. Changing a principle is a Governance decision, not a detail to introduce quietly through a feature or implementation work item.
The delivery lifecycle describes the activities that move work from an understood need to a verified and closed result. Use it to determine what the work needs next and when existing project knowledge may need to be created, updated or checked.
The lifecycle is not another set of layers and it is not a strict waterfall. Layers identify where decisions and project knowledge belong; lifecycle steps describe what people and agents are doing. Each step names the layer or layers most directly responsible, but it may also use information from other layers and can return decisions to them when something changes.
Each step shows its main focus and primary ADEL layer or layers. The primary layer is the one most involved in that step. Other layers may also provide information or receive updates.
Clarify the problem or opportunity, who it affects, the desired outcome, the relevant constraints and what success should look like.
Create or refine the product requirements until the intended behavior, scope and success criteria are clear enough for design and later verification. Add only the detail the work needs.
Create or update the approved design needed to meet the requirements. Record an important architectural decision separately when future work will need its reason, alternatives or consequences.
Organize how the approved change will move into implementation. Define the delivery scope, identify dependencies, decide the sequence and confirm that enough is known to begin.
Use a separate delivery plan only when it improves coordination, transfer or recovery of that information.
Divide the work only as much as delivery needs. Give each work item a clear outcome, boundary and acceptance criteria. For a small change, an existing issue, ticket or concise instruction may be sufficient.
Inspect the current system, make the required change and update the relevant tests and documentation. Keep the implementation within the agreed scope and the approved design.
If implementation would change an approved requirement or System Design decision, return that decision to the responsible layer instead of changing it silently in the code.
Check the delivered change against the relevant requirements, design decisions, constraints, acceptance criteria and required checks. Retain enough evidence to show what was evaluated and state the result of each expectation.
A failed, unperformed or unverifiable requirement cannot be reported as verified. Closing despite that result is a separate acceptance decision: project policy must permit an exception, and the approver must accept it.
If verification reveals a requirement, design or implementation gap, return each affected decision to the responsible layer before considering the work complete.
Each step includes its main focus; this is not a required output or document. “Primary” names the layer or layers most directly responsible for that step.
Any step may return work to an earlier one when new information changes an assumption, requirement, design or plan. Return only as far as needed, update the source of truth for the affected decision, and then update later work before continuing.
Verification can occur throughout delivery. At closure, the available evidence is checked against the relevant requirements, design decisions, constraints and acceptance criteria. A finding can return work to the earlier step responsible for the affected decision.
Work generally moves through the seven steps in order, from Understand the need to Verify and close. If new information changes an earlier decision, return to the step and layer responsible for that decision. Update the source of truth and any later work that depends on it before continuing. Governance principles, agent instructions, security policy and required checks apply in every step.
A source of truth is the record the project treats as correct for a particular kind of information or decision. ADEL does not treat one document, tool or repository as the source of truth for every question. Each layer is responsible for different decisions, and the project identifies the source of truth for each one.
A conflict exists when a record, instruction or implementation contradicts a source of truth. Resolve it by separating the decisions involved, finding the responsible layer and approver for each one, and updating the affected records before work continues.
A project has several sources of truth, each with a defined responsibility.
A record is a source of truth only for the decisions it was approved to hold. The newest file, latest prompt or current code is not automatically the one to follow.
For example, an accepted decision record holds one architectural choice, while the approved design describes the system as a whole. If they disagree, determine which decision is current and update the approved design so the two records agree.
Start by identifying the question the conflict raises. The question points to the ADEL layer responsible for the decision and the project knowledge that normally carries it.
Code and configuration show what currently exists, but they do not decide what the product or approved design should be. Treat the current system as evidence to inspect. If it contradicts an approved decision, resolve the disagreement rather than assuming the code is the source of truth.
First identify what kind of decision is being made; this determines the ADEL layer responsible for it. Then identify the approver. For example, a database architecture choice belongs to System Design, while project policy may name a technical lead as its approver through the decision-record process.
The two views below show where to look when different layers or records disagree. They do not rank every document from most to least important. Each source of truth applies only to the decisions it was approved to hold.
Read from Governance down. Each layer provides rules or decisions that the next layer must follow. A source of truth applies only to the decisions held by its own layer.
Sets project boundaries, decision authority and rules for change or exception.
Defines the required outcomes, behavior and acceptance criteria within those boundaries.
Defines how the system is intended to meet the approved requirements.
Organizes the approved work, dependencies, conditions required to start and release approach.
Carries the information and limits for implementing a specific work item.
Records what was checked, the evidence obtained and the verification result.
Assurance appears last because it evaluates the delivered result. Its verification record is the source of truth for what was checked, but it does not redefine Governance, requirements or design.
Agent instructions apply across all six layers. They tell an agent how to use this knowledge, but they do not override decisions made in any layer.
Do not use the filename or modification date as the first test. Compare which decisions the records cover and whether the project has made one the source of truth.
Do the records address the same decision?
Each record applies to its own work. Neither one replaces the other just because it is newer.
Has the project marked one record as current and approved for this decision?
Mark the other record as replaced, or update it, so nobody follows it by mistake.
Do not choose the newer file by assumption. Ask the approver to resolve the overlap.
Two task files normally describe separate pieces of work, so neither automatically outranks the other. A newer task file replaces an earlier one only when it says so and has been approved.
A new request, technical limitation, failed check or other fact learned during delivery may affect more than one part of the project. Identify the separate decisions it creates before choosing a response, so each decision is resolved in the correct ADEL layer by its approver.
The project is already implementing a marketing website. Its approved Governance principles require an accessible experience and a defined homepage performance budget. The client then asks for a large autoplay background video. Before adding it, the team separates the decisions raised by the request.
Must the existing accessibility and performance rules remain unchanged, or may an approved exception be considered?
Is the background video now a requirement, and what visitor outcome is it expected to improve?
How can the media be delivered without violating the approved constraints—for example, through a poster image, reduced motion behavior or deferred loading?
Does the approved change require a new work item, additional content preparation or more verification before release?
Ask the approver for each question to resolve it, update the affected project knowledge and later work, and then continue delivery. The work returns to several layers in this example, but it does not restart from the beginning.
Read the diagram from top to bottom for each decision affected by the conflict. Each box is a step in resolving the disagreement, not a required document. “Resolve” means the approver decides what should apply. “Update” means bringing the affected records, instructions and work back into agreement before continuing.
Repeat the flow for each decision affected by the same finding. Continue only when the relevant project records and work agree—not merely because someone selected the newest file.
The relationship column shows whether each example compares knowledge across layers, within one layer or between the Agent execution overlay and a layer. A higher layer constrains a lower layer only for its own decisions. For two records in the same layer, check what each one covers, whether it is approved and whether one says it replaces the other.
| When this happens | Relationship | What to do |
|---|---|---|
| Implementation conflicts with a product requirement or governing principle | Across layers — Execution compared with Product Definition or Governance | Pause the affected implementation. Correct the work, or have the approver intentionally change the requirement or principle before continuing. |
| Implementation conflicts with the approved design | Across layers — Execution compared with System Design | Treat the disagreement as a System Design question. Change the implementation to follow the approved design, or have the approver revise the design and record the important decision when future work will need it. |
| A decision record and the approved design disagree | Within System Design — two records may cover the same decision | Determine whether the decision record is current, accepted and relevant to the affected part of the system. If it is, apply that decision and update the approved design. If it is not, correct or replace the record. |
| Agent instructions conflict with product or design information | Agent execution overlay to layer — agent instructions compared with Product Definition or System Design | Correct the agent instructions. They tell agents how to use project knowledge; they cannot redefine requirements, System Design or governing principles. |
| Existing code conflicts with the approved design | Across layers — current implementation compared with the approved design | Do not assume the code is correct because it already exists. Determine whether the code is outdated, incomplete or evidence that the approved design needs review, then ask the approver to resolve the disagreement. |
| Two records in the same layer disagree | Within one layer — two records have overlapping scope | Determine which decision is current, approved and relevant to the affected work. Update or replace the other record so the project no longer has two approved interpretations. |
Choose a feature, fix or configuration change that affects the delivered system and try to answer the questions below. If an answer cannot be found from the project’s existing records and tools, at least one required connection is missing.
Find the business need or approved requirement that explains it.
Find the relevant approved design, any important recorded decision and the project constraints.
Find the checks performed, their results and the implementation revision they evaluated.
You do not need a dedicated traceability tool or document to answer them. For many projects, references between requirements, design documents, work items, pull requests, tests and CI results provide enough information.
This diagram is the reusable pattern. It answers which kinds of information should be connected for any feature or fix, without prescribing filenames or tools. Each box represents project knowledge or work, not necessarily a separate file. An arrow means the later item keeps a reference to the earlier item that explains or authorizes it.
Each arrow is a reference, such as a requirement ID in a work item, a work-item link in a pull request or a test result linked to the requirement it checked. These references may be fields or links in tools the project already uses; they do not require separate files.
Add each reference when you create or update the later record. For example, a work item should name the requirement it implements, and a verification result should name the requirement or work item it checked. The examples use BN for business need, FR for functional requirement and NFR for non-functional requirement. Recording these links during the work avoids reconstructing the history afterwards.
| When working here | Keep a reference to | Example |
|---|---|---|
| Requirement | The business need or outcome it supports | Supports: BN-01 |
| Approved design | The requirement or requirements it meets | Meets: FR-08 |
| Decision record, when needed | The design or requirement affected by the decision | Applies to: FR-08; Contact submission design |
| Work item | The requirement and relevant approved design | Implements: FR-08; Contact submission design |
| Implementation / pull request (PR) | The work item that authorized the change | Completes: Task 01 |
| Verification | The requirement or work item being verified and the supporting evidence | Verifies: FR-08; PR #12; CI run #1842 |
This is the general pattern from 7.2 applied to actual project records. A marketing website needs a contact form so prospective clients can send an inquiry. The example follows that need through the requirement, approved design, work item, pull request and verification result, using identifiers and references someone could search. Here, the project also records server-side email delivery as an important design decision; a project that keeps the same decision clearly in its approved design would not need a separate decision record.
Use this direction to check delivery coverage: did the original need become an approved requirement, guide the design and implementation, and result in evidence that the expected behavior works?
Use this direction before changing or removing code: find the work item that authorized it, the design decisions and constraints it must follow, the requirement it satisfies, and the business need that may be affected.
Read downward when checking whether an approved need was fully delivered and verified. Read upward when investigating existing code, assessing the impact of a change or deciding whether the code can be removed safely. The optional decision record remains attached to System Design rather than becoming another required rung.
Choose based on how difficult the relationships are to follow and how serious a missed connection would be. A small project may need only direct links. Add consistent identifiers, a shared view or formal controls when work spans more records and systems, or when the project must prove that every requirement was addressed.
The complete path fits within a few records in one repository or tool.
Example project: one person and a coding agent building a marketing website.
Keep links or identifiers between the requirement, work item, pull request and verification result. Do not create a central traceability view while these links remain easy to follow.
FR-08 → Task 01 → PR #12 → CI run #1842
Related work spans several teams, repositories, releases or planning systems.
Example project: an online software product with separate web, service and platform teams.
Use consistent identifiers across requirements, the approved design, work items, pull requests and CI. Add a central traceability table or generated view when search and tracker backlinks no longer show the complete path.
FR-142 links to two design sections, three work items assigned to different teams, four pull requests and their test runs.
The project must formally demonstrate coverage, approval and verification.
Example project: a payment authorization service subject to audit and controlled release.
Maintain reviewed mappings from each relevant requirement through design and implementation to verification evidence, including status, approval and the exact revision evaluated.
REQ-27 → design control DC-08 → change CHG-104 → test report TR-61 → release approval
These are examples, not fixed project-size rules. A small but high-risk change may require controlled traceability, while a large but low-risk project may still be understandable through well-maintained links and search.
Section 4 defined the kinds of project knowledge ADEL uses. This section explains how a project can record and store that knowledge without reorganizing every tool or creating a directory for every layer.
A record may be a Markdown file, a Jira item, a page in a product or architecture platform, a continuous integration (CI) result or another source the project already trusts. People and agents with access must be able to find the current information, understand which decisions it records and know which source to follow if records disagree.
Start with the information itself, then decide how and where to keep it. The same order works for a new project, an existing project, a Git-based workflow or a project that uses several external systems.
Identify which ADEL layer the information belongs to.
Use an existing file, page or tool when it already carries the information clearly.
Name the source of truth and make it clear who can access it.
Create, copy, split or move a record only when the source of truth is hard to access, unclear, likely to disappear or insufficient as evidence.
For any important piece of project knowledge, answer three questions separately: which ADEL layer does it belong to, which file, page or tool records it and where is the current record stored? ADEL defines the layers; each project chooses its records and locations.
The type of project knowledge: Governance, Product Definition, System Design, Delivery Planning, Execution or Assurance.
The file, page, ticket, report or other source that keeps the information available. Product briefs, PRDs, architecture documents, ADRs, tickets, handoffs and verification reports are examples, not names required by ADEL.
The repository or external system where the current source of truth is kept.
These examples follow the same order—layer, record, then location—but end in different storage arrangements.
The work item is maintained with the code, so the person or agent doing the work can retrieve its approved scope, constraints and acceptance criteria from the repository.
The product platform remains the source of truth for the requirements. The repository work item cites it and carries only the approved information needed when direct access is unavailable.
CI retains the raw test output. The repository record states what was verified, the conclusion and the link to the relevant CI run.
The table expands the same three questions across all six layers. The record names and locations are examples, not required ADEL filenames or directories.
| ADEL layer | How it may be recorded | Where it can live |
|---|---|---|
| Governance | Governance principles, policies | Repository, engineering handbook or a governance platform |
| Product Definition | Product requirements document (PRD), requirements or an existing product specification | Repository, wiki or a product-management platform |
| System Design | Blueprint, architecture documentation | Repository or an architecture platform |
| System Design | Architecture decision records (ADRs), when an important decision and its reason must be kept | Usually the repository, close to the code the decisions affect |
| Delivery Planning | Delivery plan, handoff, sequencing and dependency information | Repository, planning system or both |
| Execution | A work item, such as a task or issue | Repository when the person or agent needs the project knowledge outside the tracker; may reference an external work item |
| Execution | Implementation | The source repository |
| Assurance | Verification evidence and, when useful, a verification record | CI or test platform, repository or both |
| Assurance | Traceability links and, when useful, a central table, matrix or tool view | Across the connected systems; a repository table when one shared view must remain available |
Provides practical instructions for how agents should find project knowledge, work within project boundaries and verify their changes.
The Agent execution overlay is shown separately because it supports work across all six layers. It does not become a seventh layer or take responsibility for Governance, Product Definition, System Design, Delivery Planning, Execution or Assurance decisions.
After identifying the ADEL layer, check whether an existing file, page or tool already carries that information clearly. Its name does not need to match ADEL terminology. What matters is which decisions it contains and whether the project treats it as the source of truth for those decisions.
The examples below use familiar names while still serving clear ADEL responsibilities.
| Existing name | ADEL responsibility | Why it fits |
|---|---|---|
| product-spec.md | Product Definition | It states the intended users, scope, requirements and acceptance criteria. |
| technical-overview.md | System Design | It describes the intended components, boundaries and interactions. |
| docs/decisions/ | System Design decision records | It preserves important technical choices, their rationale and replacement status. |
| AGENTS.md | Agent execution overlay | It gives agents repository-specific instructions, limits and verification commands. |
Keep terminology the team already understands. Rename or recreate a record only when the existing name or structure makes its purpose difficult to understand.
After choosing the source of truth and its location, confirm that the people and agents doing the work can reach the relevant information. The source may stay in Jira, Confluence, a continuous integration system, an architecture platform or the repository; ADEL does not require it to be moved into Git.
Use the source of truth directly when the person or agent can reliably reach it and is allowed to. Add a copy in the repository only when the work needs information it cannot obtain directly—for example, when a coding agent cannot access Jira. The copy identifies its source and contains only the approved information needed for the work.
Naming Confluence, Jira or another system as the source of truth is not enough if the agent cannot reach it. The work must provide either approved direct access or an approved work-item-specific copy of the relevant information.
Can the agent access the relevant part of the source of truth through an approved connection or account?
Give the agent only the access needed for the work, preferably read-only. The work item identifies the relevant page or section and, when later changes could matter, the version or date used.
An approver copies or approves the requirements, constraints and acceptance criteria needed for the work item, then places them in a record the agent can access.
Can that information be provided and confirmed as current?
Record the source of truth, link, version or retrieval date, and who supplied or approved the copied information when that confirmation matters.
The agent reports the missing information and waits for approved access or an approved work-item-specific copy. It must not guess what the inaccessible source says.
In this example, the agent cannot open Confluence. The product owner places only the requirements needed for Task 01 in the accessible work item and records the Confluence page, version and retrieval date. Confluence remains the source of truth; this block identifies the version used for the work item.
## Source details Source of truth: Confluence — Contact Form PRD Source location: [internal Confluence link] Version used: 12 Retrieved: 10 September 2026 Copied information approved by: Product owner Relevant requirements for Task 01: - FR-05: Invalid input is rejected in the browser and on the server, with accessible errors. - FR-07: Show a useful response when delivery fails. - FR-08: Deliver valid inquiries to the shared inbox. - NFR-04: The form-handling path does not retain a copy of an inquiry after forwarding.
The copied block is not a second PRD. If the Confluence requirements change, the work item must be checked and updated before the agent relies on it again.
Do not give an agent unrestricted enterprise access or a person’s credentials. Direct access should follow the project’s security controls and be limited to the systems, spaces and actions needed for the work.
These examples show when the external system can stand alone and when an approved copy in the repository serves a different purpose.
| External system | What to add in the repository, when useful |
|---|---|
| Jira tracks priority, assignment, dependencies and workflow state | Add a repository work item when the person or agent doing the work needs approved scope, constraints or acceptance criteria without relying on Jira access |
| CI executes the automated checks and retains their raw results | Add a verification record when the project must keep what the results showed, what else was checked and what remains unverified |
| An architecture platform may hold the diagrams and the system model used as the source of truth | Add a summary of the approved design in the repository only when developers or agents need that information beside the code and cannot reliably use the platform directly |
| A pull request records a specific change, its review discussion and its diff | Add traceability references in the pull request, or maintain a shared view when direct links no longer reveal the requirement, design, work item and verification connected to the change |
Section 8.3 asks whether the person or agent doing the work can reach the information now. This subsection asks a different question: will the next person or agent still be able to find the decision, information or conclusion after the current conversation, meeting, CI run or work session is over?
This example applies Sections 8.1–8.4 to a project that already has documents and tools. It covers how to identify and organize the project’s existing records. Section 11 combines this work with the other steps needed to adopt ADEL across the project.
Use this list as a starting point for the inventory. A source may support more than one layer, so inspect its actual content rather than assigning it by filename alone.
| Existing source or record | What it may already provide |
|---|---|
| README.md | Project overview, setup and entry-point information |
| docs/system-design.md | Approved design |
| Jira epics | Product requirements, delivery scope or planning information |
| GitHub Issues | Work tracking, and possibly work-item details |
| docs/decisions/ | Decision records and architectural decision history |
| Pull requests | Implementation history, review information and traceability links |
| CI runs and test reports | Verification evidence |
| Engineering handbook | Governance principles, engineering policy or working guidance |
| CONTRIBUTING.md, developer guide | Repository working conventions |
| Existing agent instructions | Agent instructions |
Missing and conflicting information require different responses. If no approved design exists and the gap is causing problems, create one. If three architecture documents disagree, first use Section 6 to identify the source of truth for each disputed decision.
Use the smallest record structure that keeps current project knowledge easy to find and the necessary evidence available. This changes how knowledge is divided across files, pages or tools; it does not remove an ADEL responsibility.
The distinction below separates information used across many changes from records created only when a specific decision, work item, handoff or verification result must be kept.
These records carry project knowledge used across many changes. They may be short, combined with other records or stored outside the repository, but the current knowledge must remain available.
Review when project-wide rules, constraints or decision authority change.
Review when the intended users, outcomes, scope or requirements change.
Review when system boundaries, components, data flows or integrations change.
Review when agent instructions, boundaries or required checks change.
Create another record when a decision, work item, handoff or result must remain available and the information is not already preserved elsewhere.
The left column shows the information that is always needed. The other two columns show when a short entry is enough and when a separate record is useful.
Tests, review and CI evidence may be enough for the immediate change.
Keep a verification record when the conclusion, revision checked or remaining gaps must be available later.
Direct links between the requirement, work item, change and test result may be enough.
Add a central traceability table, matrix or tool view when those links span too many records or an audit requires one view.
A concise section in an existing technical document may be enough.
Use a separate or more detailed design record when the system can no longer be understood or maintained from the concise description.
These two repository layouts apply the same ADEL responsibilities with different amounts of separation. They are examples, not required directories or migration targets.
project/ |-- README.md |-- AGENTS.md | |-- docs/ | |-- project-principles.md # A short list of principles is enough | |-- prd.md # As short as the intent allows | |-- blueprint.md # As short as the design allows | |-- adr/ # Added when important design decisions need a record | |-- tasks/ # Added when work-item details must remain available | `-- verification/ # Added when results must remain available | |-- src/ `-- tests/
Governance principles, product intent and requirements, and the approved design each use one short file. Decision, work-item and verification directories are added only when work creates a continuing need for those records.
Section 9 explains how complexity, risk and legal, contract or audit requirements affect how much detail and separation a project needs.
Choose from the project’s actual complexity, lifespan, contributors, risks and legal, contract or audit requirements—not from team size alone. A five-person medical-device project may need stricter approvals and more evidence than a fifty-person internal application. Section 8.6 explains which records can remain concise or be created only when needed. This section helps decide the detail, record organization and change control each project area needs.
Use the steps in order. The profile provides a starting point; the project’s actual conditions determine the final choices.
Learn how much detail to keep, how to organize records and how changes will be controlled.
Pick the example closest to your project to get starting values and guidance.
Change any starting value that does not fit the project’s actual conditions.
Review them when risk, scope, contributors, lifespan or legal, contract or audit requirements change.
Each dimension answers a different question: how much to write, how to divide records and how strictly changes are approved. A profile suggests a starting value for each, but the values do not have to move together. For example, a small application may use concise, combined records while still requiring strict change control because it handles regulated data.
How much information must each layer record for people and agents to work without guessing?
Short statements cover the important intent, rules, design and evidence.
Structured and versioned specifications cover several product areas, user scenarios and constraints.
How should project knowledge be divided across files, pages, tickets or systems?
Related information shares a small number of records that remain easy to navigate.
Different layers, domains or subsystems use separate records with clear record maintainers and links.
How much review, approval and evidence is required before a decision or change is accepted?
Contributors update records directly when project policy allows it, and changes use the normal review workflow.
Named record maintainers, approvers, version status and retained evidence control important changes.
Each profile combines a practical example with typical starting values for the three dimensions. Choose the closest one, then change any value that does not fit the project.
A clickable prototype used to test whether prospective users understand a new service.
Few contributors, limited lifespan and low consequences if the experiment is discarded.
The marker shows a relative starting position, not a score or target.
The guidance for each profile is a starting point. Adjust any project area that does not fit. Every ADEL layer still applies.
A profile suggests a starting value for record organization, such as Combined or Separated. Apply that guidance to each kind of project knowledge. Keep related information together while the record remains easy to read and update. Split it when parts have different maintainers, change at different times, need different reviews or make one record too long.
One record remains easy to navigate, and its product areas are maintained and reviewed together.
Product areas become difficult to navigate together or have different record maintainers and change schedules.
One design explains the important components, boundaries and flows clearly.
Independent subsystems or domains need different record maintainers or deeper design detail.
The rules apply project-wide and can be reviewed by the same approver.
A distinct governance domain requires its own record maintainer, approval process or policy—for example, a separate data-retention policy.
A decision log still keeps each decision, rationale, status and replacement relationship distinguishable.
An important decision must be reviewed, linked, replaced or found independently.
The same setup, boundaries and checks apply throughout the repository.
A directory or subsystem genuinely needs different commands, constraints or verification instructions.
The work produces one clear outcome with one set of acceptance criteria.
It contains independently deliverable outcomes, different assignees or sequencing that must be tracked separately.
The evidence supports one reviewed conclusion for the same change or release.
Evidence belongs to distinct capabilities, releases, risk domains or independently accepted work.
Choose a starter template because the project is missing a useful record, not because every ADEL project must use the complete set. If an existing document, ticket, wiki page or project system already holds the information as a source of truth, keep using that source.
The blank, copyable versions are kept on the ADEL Starter Templates page. Work with ADEL shows completed examples inside one project. The Framework keeps only this overview so the rule, the reusable structure and the worked example are not confused.
The original ADEL templates are covered by the ADEL license and additional permission. Organizations and consultants may adapt them for delivery work under those terms.
These records keep information that remains useful across many changes. Start with a short record only when an existing source of truth does not already serve the same purpose.
| Starter record | ADEL responsibility | Use it when |
|---|---|---|
| Governance principles | Governance | The project needs one maintained place for rules that apply to every change and identify who may approve exceptions. |
| Product intent and requirements | Product Definition | The project needs one maintained source for its users, intended outcomes, scope, requirements and measures of success. |
| Approved design | System Design | People and agents need one maintained source showing the intended components, boundaries, data flows, integrations and operating design. |
| Agent instructions | Agent execution overlay | An agent needs repository-specific instructions, boundaries, commands and required checks. |
Create one of these records when a decision, handoff, work item or verification result must remain available after the current conversation or agent session ends.
| Starter record | ADEL responsibility | Use it when |
|---|---|---|
| Decision record | System Design | An important design decision and its rationale need to remain understandable after the immediate work ends. |
| Delivery plan | Delivery Planning | Another person, agent, team or session needs the approved scope and supporting information required to continue delivery. |
| Work item | Execution | One piece of work needs clear scope, an assignee, constraints and acceptance criteria that must remain available beyond the current conversation. |
| Verification record | Assurance | The result of a check, what was checked or its supporting evidence must remain available after the current work item or tool run. |
A central traceability table gives the project one maintained view of the connections between needs, requirements, design, decisions, work, implementation and evidence. Direct links are enough while people can still follow the complete path.
| Starter record | ADEL responsibility | Use it when |
|---|---|---|
| Central traceability table | Traceability across the six layers | People need one maintained view connecting requirements to design, decisions, work items, implementation and verification evidence. |
Adoption sets up how a project will use ADEL. It is different from the delivery lifecycle in Section 5, which describes how each piece of work moves from an understood need to verification and closure. All six layers and the Agent execution overlay still apply, but their records can start small. A new project can begin with concise Governance principles, product intent and requirements, an approved design and agent instructions. An existing project should keep the sources that already work and add or reorganize records only when the work requires it.
Use Section 9 to choose how much detail, record separation and change control the project needs. These choices may differ across parts of the same project.
For an existing project, list the documents, tickets, tools, instructions and evidence people already use. Identify the ADEL layer or Agent execution overlay each record supports. For a new project, decide where the initial project knowledge will be kept.
Make sure people and agents can find the Governance principles, product intent and requirements, approved design and agent instructions. Keep an existing source when it already provides the right information. Otherwise, create a concise record.
For each important decision, identify its source of truth and approver. An approver may be a named person, a role or a process defined by project policy. Link to existing sources instead of creating competing copies.
Create a decision record when an important System Design decision and its rationale need to remain available. Keep a delivery plan when scope, dependencies or responsibility must transfer. Create a work item when its scope, constraints and acceptance criteria must remain available beyond the current conversation or session.
Check the implementation against the relevant Governance principles, requirements, approved design, accepted decision records and acceptance criteria. Keep the results and evidence when future work, review or policy will need them. Use direct references for traceability and add a central view only when those references are difficult to follow.
After several work items, review what happened. Combine records that repeat the same information. Add detail or clearer links where people or agents repeatedly miss project knowledge, cannot find a decision or lack evidence.
Before implementation starts, confirm that this work is ready.
Before closing this work, confirm that the result and its evidence are complete.
The project creates files or process steps even when they do not help anyone make a decision, perform the work or verify the result.
| Problem | What happens | How to correct it |
|---|---|---|
| Governance principles contain coding rules | Project-wide rules become difficult to find among implementation details that change frequently. | Keep project-wide rules, constraints and decision authority in Governance principles. Put repository instructions in agent instructions and coding conventions in the project’s engineering guidance or automated checks. |
| Agent instructions copy all project knowledge | Requirements, design information and rules are duplicated. The copies can become outdated, and the agent receives more information than the current work needs. | Keep agent instructions concise. Tell the agent where to find the Governance, Product Definition, System Design, work-item and Assurance sources of truth instead of copying their contents. |
| Every implementation choice gets a decision record | The project accumulates many low-value records, making important System Design decisions harder to find. | Create a decision record when an important System Design decision and its rationale need to remain understandable after the immediate work ends. |
| Every change requires a formal handoff | A separate handoff repeats information already available in the work item and delays straightforward work. | Use a separate delivery plan when sequencing, dependencies, release scope, migration needs or responsibility must transfer between people, agents, teams or sessions. |
| Every template becomes a required file | The project creates empty, repeated or irrelevant files simply because a template is available. People stop trusting or maintaining them. | Use a template only when the project needs that information in a separate record. Keep project knowledge used across changes as concise as the project allows, and create other records when a decision, handoff, work item or verification result needs to be preserved. |
| Traceability adds identifiers without useful links | Records receive IDs, but people still cannot find the need, design, work or verification connected to a change. | Add direct references between the related records. Use a central traceability table, matrix or tool view only when direct references are difficult to follow. |
Information needed for decisions, implementation or verification remains in memory, conversations, code or a system that the next person or agent cannot access.
| Problem | What happens | How to correct it |
|---|---|---|
| A small project keeps no project records | The product intent, rules, design and verification results exist only in memory or agent sessions. Later work must guess or reconstruct them. | Keep concise records for the project knowledge people and agents need. A small project may combine information, but it still needs accessible sources for its important decisions and evidence. |
| Important decisions remain in conversations | The next person or agent cannot find the decision, its reason or the work it affects. | Update the source of truth for the layer responsible for the decision when the information must remain available after the conversation or session ends. |
| The source of truth is not updated | People and agents follow requirements, design information or instructions that no longer describe the current approved decision. | Update the source of truth when its decision changes. Include that update in the same work when later implementation or verification depends on it. |
| Copied external information has no source or version | People and agents cannot tell whether the repository copy still matches the source of truth in Jira, Confluence or another system. | Name and link the source of truth. Copy only the information needed for the work, and record the source version, date or revision when later changes could make the copy outdated. |
A decision is made or recorded in the wrong ADEL layer, or the project reports a result as complete without checking all relevant requirements and acceptance criteria.
| Problem | What happens | How to correct it |
|---|---|---|
| Product Definition and System Design contain the same decision | People cannot tell whether a statement defines the required outcome or the way the system should deliver it. | Keep required outcomes and behavior in Product Definition. Keep components, boundaries, flows and technical design in System Design. Link the records instead of repeating the same decision in both. |
| Passing tests are treated as complete verification | The tests may not cover every relevant requirement, System Design constraint, security requirement or acceptance criterion. | Check the delivered change against every relevant requirement and acceptance criterion, and record the supporting evidence. Record anything not checked as Not verified or Unable to verify rather than reporting the whole change as verified. |
| Implementation silently changes a requirement or System Design decision | A local code choice changes an approved outcome or system boundary without review by the approver for that decision. | Stop the affected implementation, identify the layer responsible for the decision and ask its approver to resolve it. Update the affected sources of truth before continuing. |
The entries are grouped by the role they play: an engineering foundation that ADEL complements, an independent approach that addresses a related problem, or a tool-specific example of how one part of ADEL can be implemented. Each entry explains what the referenced work provides and what ADEL contributes when people and agents use it together. None is a required product, provider, standard or development method.
External standards, conventions and product documentation were last reviewed in September 2026. Use the linked original sources for current details.
Third-party product and company names are used only to identify the referenced tools and sources. Their inclusion does not imply affiliation with or endorsement of ADEL.
ADEL complements these established practices. It shows where their outputs fit, who approves related decisions, how agents find them and how they connect to later work and evidence. It does not replace a requirements standard, architecture practice or organizational software lifecycle.
ISO/IEC/IEEE 29148 defines requirements-engineering processes and the information they produce across a system or software lifecycle.
ADEL places product intent and requirements in Product Definition, requires the project to name who may approve changes and links the requirements to the approved design, work items and verification evidence. People and agents can use the format the project already has; ADEL does not replace the standard or require its document structure.
Michael Nygard’s ADR practice gives a significant architectural decision a short record of its background, decision, status and consequences.
ADEL treats an ADR as a decision record in System Design. The project names its approver and links it to the requirements, work items and verification it affects. An ADR is one possible record, not a requirement for every implementation choice.
MADR provides a structured decision-record template covering the problem, decision drivers, considered options, outcome, consequences, confirmation and decision participants.
When a project uses a MADR-style record, ADEL identifies the responsible layer, while the project identifies the approver and links the decision to affected requirements, work items and evidence. MADR remains a separate template practice; ADEL does not require its format.
arc42 provides an adaptable structure for architecture documentation. The C4 model provides a hierarchy of system, container, component and code views.
ADEL treats relevant architecture records and views as part of the approved design. The project names who may approve changes and links the design to requirements, work items and verification. A project chooses how much architecture documentation it needs; ADEL does not require either structure or diagram set.
ISO/IEC/IEEE 12207 provides a broad framework for software lifecycle processes and allows organizations to use different lifecycle models and methods.
Within the lifecycle a project already uses, ADEL shows where decisions are recorded, how agents find them and which evidence supports closure. It is not a substitute for an organizational software lifecycle or the standard.
These independent projects also give agents specifications or instructions that remain available between sessions. ADEL can use their outputs while adding approval, conflict and verification responsibilities around them. ADEL does not reproduce or require these approaches.
Spec Kit provides a command-based workflow for creating project principles, specifications, plans, tasks and implementation.
A project can use suitable Spec Kit outputs as ADEL records. ADEL adds Governance, Assurance, a requirement for the project to name an approver for each important decision and rules for conflicts with records outside the Spec Kit workflow. It does not copy or require Spec Kit’s commands, sequence or templates.
OpenAI describes using a short AGENTS.md as a “table of contents” that points coding agents to a structured repository knowledge base.
ADEL separates agent instructions, which say how an agent works, from project decisions, which say what the project must do. It connects the instructions to six responsible layers. A source of truth can remain in Jira, Confluence, CI or another approved system when the agent can access it or receives an approved copy of the information needed.
Kiro Specs uses a structured workflow that turns a feature or bug description into requirements, a technical design, and implementation tasks.
A project can use Kiro requirements, designs and tasks as ADEL records. ADEL also covers Governance, Assurance, approvers, conflicts and traceability across other tools. It remains independent of Kiro and does not require records to move.
BMAD provides workflows that can produce product briefs, PRDs, architecture information, specifications, epics and stories before implementation and review.
A project can use suitable BMAD outputs as ADEL records. ADEL identifies the responsible layer for each important decision; the project names its approver and connects those outputs to records and evidence outside the BMAD workflow. It does not require BMAD’s sequence or roles.
AGENTS.md is an open Markdown convention for giving coding agents instructions and project information, including more specific guidance in nested directories.
ADEL connects agent instructions to the six layers and states which project decisions they may not override. The framework does not require the AGENTS.md filename or define a competing file format.
These product documents show that coding tools can find instructions stored at repository or directory level and use them in later sessions. They are implementation examples only: each tool defines its own supported files, which instructions to follow first and its limits.
Codex documents how it finds AGENTS.md instructions in global, project and nested directory scopes, and how instructions closer to the working directory take precedence when guidance conflicts.
ADEL connects the instructions Codex finds to the project’s responsible layers, approved decisions and evidence. Codex documentation remains the source of truth for Codex behavior.
GitHub documents repository-wide, path-specific and agent instruction files supported by different Copilot surfaces.
ADEL connects Copilot instructions to the project’s responsible layers, approvers and verification evidence. ADEL does not require Copilot or replace GitHub’s rules for supported files and instruction scope.
ADEL keeps people and AI agents working from the same current project knowledge. Each important action links back to the need, requirement, rule, design decision or work item behind it. It also links forward to the evidence used to review and close the work.
The six layers give each kind of decision a responsible place. The seven lifecycle steps show how people and agents use those decisions while work moves from an initial need to a verified result.
When new information changes an earlier decision, the project returns to the responsible layer. The approver resolves the decision, its source of truth is updated and later work is checked before delivery continues.
The Agent execution overlay tells coding agents where to find each source of truth, which repository rules to follow, which required checks to run and how to report results. It supports every layer without replacing the decisions held there.
Projects may use different files, tools and amounts of documentation. What matters is that people and agents can find the current decision and its approver, trace it to the work it affects and see the evidence used to close that work.
Write decisions down where people and agents can find them, link every change to the decision behind it and verify the result with evidence.
Every meaningful action should connect back to the need, requirement, rule, design decision or work item that authorized it and forward to the evidence used to verify it. Keep this information current and accessible so people and agents can continue the work without relying on memory or previous conversations.
© 2026 Mark A. Basco. The ADEL content published at marklesterbasco.com/adel—including the Framework, Playbook, Work with ADEL walkthrough and starter templates, and their original text, diagrams and prompts—is licensed under Creative Commons Attribution–NonCommercial 4.0 International (CC BY-NC 4.0), with the additional permission stated below.
This license applies to ADEL’s published content, not the website source code, software, fonts or third-party assets. Third-party names, trademarks and works linked or referenced in these materials remain the property of their respective owners and are not covered by this license.
In addition to the rights granted by CC BY-NC 4.0, anyone may copy, share and adapt ADEL material for commercial purposes when applying it to plan, govern, design, implement, verify or close software projects:
The organization, client or open-source project may retain, use and adapt the resulting adoption and project records for its own software work. Those records may be kept in private or public project repositories. All other CC BY-NC 4.0 conditions continue to apply. Private internal records and records delivered privately to a client do not require a credit line. When a public repository or another public release includes ADEL material or an adaptation, keep the copyright notice, attribution and license link, and identify changes as required by CC BY-NC 4.0.
This permission includes internal onboarding, coaching and knowledge transfer reasonably needed to adopt or apply ADEL during software delivery. It does not cover a paid engagement that reproduces, displays, distributes or adapts ADEL material primarily to teach ADEL, including a private workshop, course or train-the-trainer program. That use requires separate written permission.
Separate written permission is required to commercially sell, license or publish a book, course, training resource, certification program, template product or similar offering that reproduces, displays, distributes or adapts substantial ADEL material. This includes using ADEL’s protected text, diagrams, prompts, examples or templates as a significant part of the offering. Noncommercial sharing and publishing remain permitted under CC BY-NC 4.0. These terms do not restrict independently written discussion of the underlying ideas or any use that applicable copyright law permits without permission.
For commercial permission, contact Mark A. Basco.
The license does not grant trademark rights in the ADEL name or visual identity. You may accurately state that a software project applies ADEL or that independently created commentary discusses ADEL. You may not describe or market a product, service, publication, course, workshop or certification as “official ADEL,” “ADEL certified,” endorsed by ADEL or otherwise authorized by Mark A. Basco without written permission.
“ADEL — Agentic Delivery & Engineering Lifecycle, © 2026 Mark A. Basco (marklesterbasco.com/adel), licensed under CC BY-NC 4.0 (creativecommons.org/licenses/by-nc/4.0/).”
“Adapted from ADEL — Agentic Delivery & Engineering Lifecycle, © 2026 Mark A. Basco (marklesterbasco.com/adel), licensed under CC BY-NC 4.0 (creativecommons.org/licenses/by-nc/4.0/). Changes were made.”
In digital formats, link the title and license name. In print, show the web addresses.
