BOUND Method v3.0

Soheil Mozaffari

doi:10.5281/zenodo.22257583

فارسی

v3.0 · Published September 2026

Boundary-Oriented Unified Development

A methodology for reliable parallel software engineering.

BOUND makes responsibility boundaries explicit, formalises what may cross them as contracts, and enables human and AI-assisted teams to execute independently under continuous verification.

Define the boundaries. Freeze the contracts. Execute independently. Verify continuously.

Freedom within boundaries. Discipline across them.

Software Architecture Parallel Engineering Executable Contracts AI-Assisted Engineering

Explore the Method Read the Publication

See the seven-phase execution lifecycle → Author: Soheil Mozaffari · ORCID 0009-0001-2428-1295 · IFEM → BOUND v3.0

BOUNDARY CONTRACT EXECUTION VERIFICATION

AGENTIC SOFTWARE / FAILURE MODE

Coding agents are fast. Shared assumptions still drift.

Claude Code, Codex, and other coding agents can implement substantial work in parallel. The risk is not agentic development itself. The risk appears when separate agents, prompts, branches, or sessions are free to invent different answers to the same cross-system question.

Context drift

Long sessions, compressed context, handoffs, and prompt changes can gradually alter assumptions that were never made explicit.

Agent-to-agent divergence

Two capable agents can make different, individually reasonable choices for schemas, errors, ownership, timing, retries, or compatibility.

Local success, system failure

Each module can compile and pass local tests while still violating an assumption held by a neighbouring module.

Silent contract mutation

An agent may “fix” an interface to unblock its task while downstream work continues against the earlier meaning.

THIS IS WHERE BOUND ENTERS

BOUND is not a brake on agentic AI. It is a control surface for reliable autonomy.

BOUND removes the cross-boundary decisions an agent should not be forced to guess. It gives human teams and coding agents the same stable execution envelope: explicit ownership, governed contracts, implementation-ready Team Briefs, and continuous conformance checks.

BOUNDARYDefine what the agent owns.

CONTRACTFreeze what neighbours may rely on.

BRIEFGive the agent a bounded execution context.

VERIFYDetect drift before integration.

See how BOUND governs agentic execution ↓

PHASE 3 · UNDER CONSTRUCTION

BOUND for Agentic Execution

The next phase explores how BOUND's explicit boundaries, contracts, verification plans, and execution contexts can become the engineering control layer around autonomous software agents. This work is under construction.

Explore Phase 3 →

OVERVIEW

Parallelism is not the problem. Ambiguity at boundaries is.

Modern engineering teams can produce software faster than ever. Human developers, distributed teams, CI systems, and AI coding agents can all work concurrently.

But increasing implementation capacity does not automatically increase system-level progress.

The failure often appears at the boundaries between independently developed parts of the system: different assumptions about ownership, schemas, units, errors, timing, retries, compatibility, or state.

BOUND moves those assumptions out of conversation and into explicit engineering artefacts.

Who decides?

The boundary — Responsibility ownership and decision rights

What may others rely on?

The contract — Externally observable obligations

How is the agreement proven?

The integration function — Conformance verification

Intensive coordination is concentrated around boundary and contract decisions, while routine implementation proceeds with substantially reduced cross-team dependency.

— Coordination-Bounded Engineering

From IFEM to BOUND

BOUND v3.0 continues and conceptually refines Interface-First Execution Methodology by making responsibility boundaries the architectural step that precedes interfaces and contracts.

THE PROBLEM

Where coordination risk actually accumulates

Software projects often appear to fail at integration, but integration is frequently only where an earlier architectural problem becomes visible. Three teams may write excellent code, their internal tests may pass, their code coverage may be strong — yet the system can still fail because the teams hold different assumptions about message ordering, timeout behaviour, authentication renewal, field encoding, retry semantics, or ownership of persistent state.

The defects are not necessarily inside the modules. They exist between them.

The conventional response is more communication. BOUND asks a different question:

Which assumptions can be removed from conversation and turned into durable engineering artefacts?

Explicit Boundaries

If ownership is clear, fewer decisions require negotiation.

Explicit Contracts

If a contract is explicit, fewer behaviours require inference.

Executable Verification

If that contract is machine-checkable, fewer mismatches survive.

ARCHITECTURE

Architecture begins with ownership

BOUND governs cross-module relationships through explicit ownership, reliable contracts, and continuous conformance verification.

BOUND does not begin by drawing arbitrary interfaces.

It begins by determining where responsibility belongs.

A boundary separates ownership domains. A contract defines the behaviour other domains may legitimately rely upon. The integration function proves that independently developed implementations continue to satisfy those obligations.

LAYER 01

Boundary

"Who gets to decide what?"

Responsibility, authority, and architectural ownership. A boundary is a line separating two ownership domains.

Ownership & decision rights
Information hiding
Mockability test
Independent testability

LAYER 02

Contract

"What may neighbouring domains legitimately rely on?"

Cross-boundary obligations such as schemas, signatures, units, timing, errors, compatibility, threading, ordering, and versioning.

Data formats & types
Error semantics
Timing & concurrency
Compatibility strategy

LAYER 03

Integration Function

"Does implementation conform to what was agreed?"

The organisational and automated function responsible for verifying compatibility and coordinating controlled contract evolution.

Schema validation
ABI compatibility
Contract tests
CI enforcement

Figure 1 — BOUND Core Model. The canonical four-stage execution model. Boundary → Contract → Independent Execution → Continuous Verification.

Boundary

Define responsibility boundaries

Contract

Formalise and freeze cross-boundary obligations

Independent Execution

Teams implement behind stable boundaries

Continuous Verification

Conformance checked throughout implementation and integration

Define the boundaries. Freeze the contracts. Execute independently. Verify continuously.

"A precise contract cannot fully compensate for a poorly chosen responsibility boundary."

— BOUND Method v3.0

CONTRACTS

A contract is more than an API signature

Cross-boundary obligations that allow independent teams to proceed without understanding one another's internal design.

In BOUND, a contract is any externally relied-upon obligation crossing a responsibility boundary.

The objective is not maximal documentation. It is sufficient precision for another team to proceed without inventing missing cross-boundary behaviour.

Consider a method returning float getTemperature(). What unit does the float represent? Can the value be absent? What happens when the sensor fails?

Contract Dimensions

Function SignaturesParameter names, types, return values, nullability

SchemasField definitions, valid ranges, units, versioning

Error SemanticsError classes, retry behaviour, failure modes

TimingTimeout expectations, latency bounds, caching

ConcurrencyThread-safety, ordering guarantees, atomicity

SerialisationByte layouts, encoding, frame structure

CompatibilityVersioning strategy, migration rules

DatabaseOwnership, migration responsibilities, access patterns

Contract Freeze

Contract Freeze means controlled change, not permanent immutability.

A contract change becomes an engineering event involving explicit change acknowledgement, compatibility decision, impacted consumer identification, versioning or migration, tests, and re-freezing. Interfaces are one class of contract, not the whole concept.

PRINCIPLES

The operating principles of BOUND

The ideas that make BOUND work.

Ownership before interface

Determine who controls a responsibility before defining how others access it.

Freedom within boundaries; discipline across them

Internal implementation remains local. Externally relied-upon behaviour does not.

Contract freeze means controlled change

Shared obligations may evolve, but not through silent mutation.

Verification is continuous governance

Contracts are not merely documents. Conformance is checked throughout implementation.

Cohesion Within, Contracts Between

The discipline at the boundary buys freedom everywhere else.

Figure 2 — Boundary-Based Parallel Development. Private module implementation coordinated through published cross-boundary contracts and a shared verification pipeline. The contract is the authoritative specification of behaviour crossing the boundary; it is not a runtime component.

Team A

Module Owner

Team B

Module Owner

Team C

Module Owner

Published Cross-Boundary Contract

Shared Verification Pipeline → Continuous Contract Verification

Cohesion within; contracts between.

LIFECYCLE

The Seven-Phase BOUND Lifecycle

From domain understanding to verifiable handover.

Understand → assign → formalise → package → build → verify → preserve.

Design & Execution Preparation · Phases 1–4

Parallel Implementation & Verification · Phases 5–6

Delivery & Preservation · Phase 7

Execution and verification overlap. Verification is not a ceremonial final integration phase. It begins as soon as concrete implementations exist and continues alongside parallel execution.

Figure 4 — Continuous Contract Verification Loop. The published contract acts as the source of truth; automated CI either permits integration when implementation conforms or forces an explicit correction of the implementation or a controlled contract revision. Mismatch detected close to the change that introduced it.

Published Contract

Source of truth

→

Implementation

Independent work

→

Automated Verification

CI / contract tests

✓ PASS

Conform → integrate. Implementation satisfies published boundary obligations.

✗ FAIL

Mismatch → fix implementation or trigger controlled contract revision. A contract change must not look like silent mutation.

PRACTICE

Where BOUND fits — and where it does not

Assessment, change control, and real-world fit.

BOUND is a strong fit when:

A system can be decomposed into meaningful responsibility domains
Multiple teams or agents work concurrently
Boundary behaviour can be specified with reasonable precision
Integration risk concentrates at known interfaces/boundaries
Automated or mechanical verification is feasible
Architecture is reasonably knowable before broad parallel execution
Large platforms, embedded systems, cross-runtime applications, infrastructure products, regulated systems
AI-assisted multi-agent implementation

BOUND may be premature when:

The domain is fundamentally exploratory
Responsibilities cannot yet be decomposed confidently
Product discovery requires rapid cross-functional iteration
Boundaries change continuously
Contracts would create artificial certainty
The system is too small for the architectural overhead to be justified

The Trade-Off

BOUND deliberately shifts effort earlier in the lifecycle.

Teams spend more effort clarifying ownership and cross-boundary assumptions before parallel execution in exchange for lower coordination pressure and lower integration ambiguity during execution.

AI-Assisted Engineering

A Team Brief becomes a bounded execution context for a human team or AI coding agent. Inside that envelope, the implementer may make local engineering decisions without having authority to silently redesign neighbouring modules or redefine shared contracts. The result remains verifiable against objective acceptance criteria.

LINEAGE

From Interface-First to Boundary-Oriented

BOUND v3.0 is the renamed continuation and conceptual refinement of Interface-First Execution Methodology (IFEM).

The change clarifies architectural ordering rather than rejecting the earlier method.

IFEM asked:

What interface must teams agree upon so they can execute independently?

BOUND asks one earlier question:

What responsibility boundary does that interface represent?

Figure 5 — From IFEM to BOUND: Conceptual Refinement. BOUND retains the core mechanisms of IFEM while making the architectural ordering explicit.

Earlier Methodology

IFEM — Interface-First Execution Methodology

Interface→ Contract→ Execution→ Verification

Interfaces were treated as the primary execution constraint.

Current Methodology

BOUND — Boundary-Oriented Unified Development

Domain→ Boundary→ Contract→ Execution→ Verification

BOUND makes responsibility boundaries the first architectural abstraction; interfaces and contracts then make those boundaries executable and verifiable.

Interfaces emerge from boundaries; boundaries should not be inferred from interfaces.

BOUND retains the execution philosophy of IFEM while making its architectural starting point explicit.

Earlier IFEM publication · DOI: 10.5281/zenodo.20621561

Frequently Asked Questions

How is BOUND different from IFEM?

BOUND v3.0 is the continuation and conceptual refinement of IFEM. The distinction lies primarily in architectural ordering: IFEM placed strong emphasis on interfaces as the mechanism enabling independent execution. BOUND retains that mechanism but asks an earlier question: What responsibility boundary does the interface represent? Interfaces emerge from the boundaries rather than boundaries being inferred from interfaces.

Does Contract Freeze mean interfaces can never change?

No. Contract Freeze means controlled change, not permanent immutability. A contract revision becomes an engineering event with an explicit compatibility decision: dependent teams know that a contract changed, why it changed, which revision they are implementing, and what migration path applies.

Is BOUND suitable for AI-assisted software development?

Yes — particularly where multiple AI-assisted teams or agents work in parallel. The Team Brief becomes a bounded execution context: mission, expected files, interfaces, valid ranges, protocol details, dependencies, mocks, acceptance tests, performance requirements, and forbidden assumptions. Inside that envelope, the agent can make implementation choices without authority to redesign neighbouring modules.

How is BOUND different from Microservices, DDD, and Design by Contract?

BOUND overlaps with several established ideas but replaces none of them. A BOUND boundary does not have to become a network service; a DDD bounded context may become an excellent BOUND responsibility domain; Design by Contract formalises preconditions and invariants while BOUND uses contract more broadly — schemas, protocols, threading, errors, timing, compatibility, serialisation, versioning.

When should a team avoid using BOUND?

When the problem remains highly uncertain: early product discovery, boundaries that shift daily, very small systems, or domains that resist meaningful decomposition. Decision rule: if the expected cost of cross-team ambiguity during execution is high enough to justify additional architectural effort beforehand, BOUND is likely a strong fit. Otherwise: explore first.

CONCLUSION

Reliable independence requires explicit assumptions

Software projects rarely fail because every module was implemented badly.

They often fail because independently developed parts of the system were built around different assumptions.

BOUND makes those assumptions visible where they matter most: at responsibility boundaries.

Teams remain free to change algorithms, internal structures, tools, and implementation techniques inside their domains. What they may not do is silently redefine behaviour that another part of the system has been told it can rely upon.

Define the boundaries. Freeze the contracts. Execute independently. Verify continuously.