Skip section navigation

Relay / fictional worked example

ADR-001 — Separate request mechanics from product workflows

On this page

Status: Accepted for the fictional design. Not an assertion about a deployed system.

Context

Relay needs to collect, assign and display maintenance requests while product strategy is still being tested. Automatic urgency, reporting and scheduling are possible future ideas, not stable requirements. The implementation will increasingly be carried out by agents working on bounded scopes.

Decision

Define a stable request storage contract and audit contract. Build intake/assignment integrations on those contracts. Keep product-specific queue behaviour in a separate orchestration component. The tool pipeline validates schemas, fixtures and tests without becoming part of the runtime business model.

Alternatives considered

A. One feature-focused application module — Fast for a small proof of concept and simpler to deploy. Rejected for this worked example because the intended sequence involves independent evolution of intake, ownership and user workflow, making the boundaries useful.

B. Service-per-capability architecture — Clear network boundaries but creates operational and distributed-systems overhead before the product has evidence it needs that scale. Rejected as premature.

C. Internal modules with explicit ports/contracts — Chosen. Enables independent work while retaining a straightforward deployment option.

Consequences

Positive: Agents can work against limited context; mechanics survive changes in product scope; contract tests can protect consumers; product experiments can happen without rewriting storage.

Negative: Interface design becomes an explicit cost. Some features will cross boundaries. Maintaining adapters, tests and decision records takes effort. Contracts can still be wrong.

Reconsider when

  • A component boundary causes repeated cross-layer changes for ordinary work.
  • Latency or transactional needs make the separation inappropriate.
  • There is strong evidence for a product capability that changes an invariant.
  • The team can no longer explain the benefit of maintaining a given abstraction.

Rule: An implementing agent may not change this decision by introducing shadow storage or a second workflow state model. It must escalate with evidence.

Consulting

Need help with the work?

We can review a design, help set up an AI-assisted workflow or work with your team on implementation.