Load Bearing

---
name: load-bearing
description: "Explore alternative software architectures through boundaries, reversibility, and borrowed models. Use when the design space is still open, not for a mandatory architecture audit."
argument-hint: "[system / feature / change to architect]"
metadata:
  kind: heuristic
---

<!--
Copyright 2026 IamK77 — Licensed under the Apache License, Version 2.0.
See ./LICENSE and ./NOTICE · https://www.apache.org/licenses/LICENSE-2.0
-->

# load-bearing

Explore alternative software architectures through boundaries, reversibility, and borrowed models. Use when the design space is still open, not for a mandatory architecture audit.

## Starting point

An architecture is a distribution of future choices. Instead of asking which pattern is correct, imagine which changes each pattern makes easy, awkward, or impossible.

Bring a question, fragment, reference, or tension. Follow whichever association becomes useful; these invitations are not a sequence to complete. Speculation should remain distinguishable from an observed fact.

## Thought experiments

### Borrow a different institution

Treat the system as a library, a marketplace, then a postal service. What becomes the catalogue, the negotiation, or the address? Transfer one structural relation, not the entire metaphor.

### Remove an assumed centre

Imagine the database, coordinator, or shared model vanished. Sketch how work could still happen. Then bring the centre back only where the alternative genuinely needs it.

### Change the time horizon

Draw the design for a one-week experiment and for a ten-year institution. The disagreement can reveal a reversible seam rather than a compromise architecture.

## A possible turn

A shared customer object ties billing, support, and identity together. A passport analogy suggests separate local records with narrow attestations; a workshop analogy instead suggests one working record with explicit custody. These are two different boundaries to explore, not two boxes to tick.

## Leave the space open

Offer a few genuinely different possibilities, a sketch, an analogy, or a sharper question when useful. Do not turn every prompt into a scored diagnostic, a completion gate, or a demand for an action plan. The human may choose a direction, combine them, or leave the question open.

If a direction is chosen, groundwork can turn it into acceptance examples; assay can test the boundary that matters.

## Optional references

Read selectively when a thread needs another perspective or a concrete technique. The notes supply possibilities, examples, and limits; none is a prerequisite or a requirement to close the exploration.

- [Record a decision without erasing its alternatives](references/adr-and-evolution.md)
- [Architecture as a distribution of future choices](references/agent-era-shifts.md)
- [Names as descriptions, not rankings](references/architecture-styles.md)
- [Control what collaborators need to know](references/boundaries-and-contracts.md)
- [Represent questions and histories deliberately](references/data-design.md)
- [Questions that expose architectural forks](references/decision-tree.md)
- [Translate a quality into an observable promise](references/nfr-realization.md)
- [Compare commitments and reversible experiments](references/tech-selection.md)