Software Concept Architect · Design — Turn Requirements into Clear Concepts

Turn Requirements into Clear Concepts

Software Concept Architect · Design

Complete the concept design with the user: confirm the three alignment sections, then write the design record. Run only on explicit $software-concept-architect-design invocation. Continue into PRD or implementation only when already authorized. If software-concept-architect-prd or software-concept-architect-build is missing, deliver the model and name the missing step.

Design principles

• Familiarity. Use a familiar concept, or a variant of one, when it meets the need.
• Specificity. Each concept serves one purpose. Do not add a second concept for the same purpose.
• Integrity. Synchronization may exclude some of a concept's behavior. It may not make the concept do something its own specification disallows.
• Two arguments. Contract → OP → concept purpose; concept selection and synchronizations → application scenarios → application purpose. Local validity does not prove overall fitness. The single-purpose criterion applies to concepts, not mechanically to applications.
• Evidence. Source facts, and label inferences and open decisions. Absence of a counterexample is not proof. Pages, entities, and code modules are only candidate clues.

Design process

Confirm each part with the user. Mark anything not yet confirmed as pending, and do not record it as a confirmed fact.

1. Check facts — With the user, identify beneficiaries, application purpose, current state, desired outcome, and constraints. In an existing system, trace actual entry points, state ownership, failure paths, and tests. Separate current from desired behavior. If the purpose is not yet stated, mark it open.
2. Propose the inventory — Write the concept inventory from references/artifacts.md and ask which concepts to include. After confirmation, write state and actions from references/spec-format.md. External identity is a type parameter with no assumed fields.
3. Review seams — Read references/criteria.md. Give all eight conclusions for each candidate. Leave disputes for the user to decide.
4. Confirm scope, then compose — Ask the user to confirm dependencies and subsets using references/sync-notation.md. Then write syncs from the specification contract, and check under-synchronization, over-synchronization, the synchronization diagram, and the MVP.
5. Write the record — Correct an evidenced misfit using the qualification standard. Write confirmed alignment into the design record. Keep pending items in exclusions and open decisions, and block only the portion that depends on them.

Design artifacts

Field rules are in references/artifacts.md.

Alignment, confirmed with the user: concept inventory, application purpose and scenarios, dependencies and subsets.

Design record, written after confirmation: Concepts, Synchronizations, synchronization diagram, exclusions and open decisions.

Standards

Standard	Use
Qualification	whether a concept qualifies
Specification contract	how to write purpose, state, actions, OP, and synchronizations
Composition	synchronization rules, the synchronization diagram, dependencies, and the MVP

Completion

• Every alignment item has a confirmation mark. Pending items appear only under exclusions and open decisions, with the portion they block.
• The concept purpose and the application purpose each have evidence of fulfillment, or are marked open.
• An entry that requires a response states success and refusal. The synchronization diagram, dependencies, and MVP meet the composition standard. The specification meets the contract.

For a first pass together, read references/example-reserving.md. For definitions and local conventions, read references/sources.md.