Right-Size Engineering

Make the least speculative engineering commitment that completely supports the required outcome.

Use macro, meso, and micro as relative perspectives on the current subject, not fixed development phases:

• Macro — purpose and system effect: outcome, users, contracts, constraints, non-goals, and consequences
• Meso — structure and ownership: responsibilities, boundaries, relationships, workflows, dependency direction, and propagation
• Micro — mechanism and evidence: behavior, state, algorithms, failure handling, configuration, tests, and operational details

A project, subsystem, module, API, or function can each be examined through all three perspectives. Do not treat a perspective as a measure of importance, change size, or permission to expand scope.

Calibrate The Decision

1. Identify the required outcome, current decision, hard constraints, available evidence, and material uncertainty.
2. Start at the perspective where the decision appears to belong.
3. Inspect the nearest adjacent perspective when needed:
   • look upward to justify purpose, scope, or enduring structure
   • look downward to confirm feasibility, behavior, failure semantics, or verification
4. Place the decision at the boundary that owns its consequences.
5. Choose the least irreversible solution supported by present requirements and evidence.

Do not perform a complete three-perspective analysis by default. Traverse only far enough to resolve material uncertainty or detect a plausible mismatch.

Stop traversing perspectives when the decision is supported at its owning level and its material adjacent consequences are accounted for. Do not continue into hypothetical impacts.

Keep The Perspectives Aligned

Require:

• an upper-level reason for every material lower-level commitment
• a structural owner for every cross-cutting responsibility
• a concrete mechanism and practical evidence for every claimed behavior
• explicit deferral when current evidence does not justify a commitment

Prefer a direct local solution when the responsibility is local. Prefer a structural solution when local changes would duplicate policy, expose an ownership gap, or leave the required outcome incomplete.

Detect Misalignment

Treat these as signs of over-engineering:

• a lower-level mechanism or abstraction lacks an upper-level requirement
• a local problem is promoted into system-wide structure without evidence
• optionality, configuration, extension points, or layers serve only hypothetical use
• the solution commits more boundaries or concepts than the outcome requires

Treat these as signs of under-engineering:

• an upper-level promise has no structural owner or concrete realization
• a local solution leaves a known invariant, caller, workflow, or contract inconsistent
• relevant failure, migration, compatibility, state, or operational effects are unowned
• confidence depends on assumptions that practical verification could test

Expand, reduce, or defer the decision only in response to such evidence. Do not mistake more engineering for completeness or less engineering for simplicity.

Composition

Apply this calibration within the primary task and follow its workflow and output format.

Keep routine perspective analysis implicit. Do not produce a separate macro, meso, and micro report or label routine reasoning with these perspectives unless requested.

Surface a perspective mismatch only when it materially affects the outcome, scope, design, risk, assumptions, deferred work, or verification.

Keep The Responsibility Bounded

Own perspective selection, cross-perspective alignment, and over- or under-engineering checks.

Do not prescribe specialized requirements, architecture, boundary design, implementation, testing, security, performance, migration, or review methods. Apply relevant project or domain guidance separately when one becomes the primary task.