The Four-Layer Model (Conceptual)

Software development is entering an era in which applications are no longer primarily human-written, but increasingly AI-built. In this shift, traditional development assumptions—centered on human authorship, review, and implicit authority—no longer scale. AI systems can generate, modify, and execute software behavior faster than human supervision, creating ambiguity around intent, permission, accountability, and learning from outcomes.

The four-layer model provides a structural separation of concerns for AI-built application development. These layers are conceptual distinctions, not phases. They represent irreducible responsibilities that cannot be safely collapsed into one another without introducing unbounded behavior or unverifiable responsibility.

Purpose

Design defines meaning, intent, alignment, and success criteria. It establishes what the system should accomplish and how success is measured.

Responsibility

Design must answer:

• What is the intended purpose and meaning of the system?
• What constitutes alignment with human intent?
• How is success defined and measured?
• What are the boundaries of acceptable behavior?

Non-responsibility

Design must not:

• Grant permission or authority to execute actions
• Prescribe specific implementation methods
• Observe or record outcomes
• Make runtime decisions about execution

Failure Mode

If Design is missing or collapsed with other layers, the system lacks clear intent and success criteria, making it impossible to determine whether outcomes align with human goals or to hold the system accountable for its behavior.

Purpose

Governance defines explicit authority, permission, and refusal. It establishes what actions are permitted, by whom, and under what conditions.

Responsibility

Governance controls:

• What actions are explicitly permitted or refused
• Who or what has authority to grant permission
• Conditions under which actions may proceed
• Boundaries that execution must not exceed

Non-responsibility

Governance must not:

• Define meaning or intent (that is Design's role)
• Perform the actual execution of actions
• Interpret outcomes or learn from results
• Make decisions about what should be designed

Failure Mode

If Governance is collapsed with other layers, authority becomes implicit or ambiguous. Execution may proceed without clear permission, or permission may be granted without explicit authority, leading to unverifiable responsibility and unbounded behavior.

Purpose

Execution performs construction and operation. It carries out the actions that have been permitted by Governance, according to the intent defined by Design.

Responsibility

Execution must:

• Carry out permitted actions within established boundaries
• Operate according to the intent defined in Design
• Respect the permissions and refusals established by Governance
• Perform construction and operation efficiently and reliably

Non-responsibility

Execution must not:

• Grant permission or authority (that is Governance's role)
• Define intent or meaning (that is Design's role)
• Learn from outcomes or modify its own behavior based on results
• Make decisions about what should be executed beyond what is permitted

Failure Mode

If Execution is unbounded or granted authority it should not have, it may perform actions without proper permission, exceed intended boundaries, or modify behavior in ways that cannot be verified or held accountable.

Purpose

Feedback observes reality and retains memory. It records what actually happened, providing a basis for understanding outcomes and informing future decisions.

Responsibility

Feedback must:

• Observe and record what actually occurred
• Retain memory of outcomes and events
• Provide accurate records of system behavior
• Make observations available for analysis and learning

Non-responsibility

Feedback must not:

• Grant permission or authority (that is Governance's role)
• Control execution or make runtime decisions
• Define intent or success criteria (that is Design's role)
• Modify system behavior based on observations

Failure Mode

If Feedback is treated as control or granted authority, it may influence execution in ways that cannot be verified, creating feedback loops that modify behavior without explicit permission or clear accountability.

The four layers are conceptual distinctions, not phases in a workflow. They represent structural separation of concerns that may operate concurrently.

Layers are not a sequential process. Design does not necessarily precede Governance, which does not necessarily precede Execution, which does not necessarily precede Feedback. The layers may all be active simultaneously, each addressing its distinct responsibility.

The layers are not a workflow. They do not prescribe a step-by-step process for building systems. Instead, they define irreducible responsibilities that must be addressed, regardless of the order or method by which they are implemented.

Each layer answers a distinct question that cannot be safely collapsed into another. Attempting to combine layers introduces ambiguity, unbounded behavior, or unverifiable responsibility.

This page is conceptual and non-normative. It explains the four-layer model as derived from the PactJSON Foundation but does not define:

• Schemas or data formats
• APIs or interfaces
• Implementation requirements
• Examples or specifications

The PactJSON Foundation remains the sole conceptual authority. This page exists to aid understanding only and may evolve or be removed without affecting the foundation.