← BOUND MethodGitHub
GUIDE / QUICKSTART

Apply BOUND without waiting for tooling.

The initial BOUND workflow is artifact-driven. Define the engineering envelope first; implementation tooling can consume these artifacts later.

1. Define the domain

State the capability and operating context. Record deployment, trust, persistence, runtime, latency, and recovery concerns that affect architectural decisions.

2. Define responsibility boundaries

For every boundary, identify an owner, owned decisions, exposed behaviour, consumed behaviour, and forbidden dependencies.

3. Freeze the cross-boundary contract

Record the observable behaviour another implementation can rely on. Include data shape, semantics, errors, timing, concurrency, compatibility, versioning, and state ownership.

4. Write the Team Brief

Give each implementer—human or agent—a bounded execution context: mission, boundary, allowed change surface, dependencies, contracts, acceptance evidence, and definition of done.

5. State required interfaces

List every cross-boundary interface and its governing contract/version. Explicitly state that no other cross-boundary dependency is assumed unless added.

6. Execute independently

Work inside the agreed boundary. Do not silently redesign neighbouring responsibilities to solve a local implementation problem.

7. Verify continuously

Turn the contract into checks before integration: contract tests, schema validation, compatibility checks, integration tests, static analysis, and CI gates as appropriate.

Important: BOUND tooling, CLI commands, and SDK imports are not documented here as existing products. They should be added only after their implementation and schemas are defined.