View

Practitioner method

Software Before Code

A working public engineering method for determining the represented domain, distinctions, invariants, boundaries, witnesses, and closure conditions before implementation mechanisms dominate the design.

At a glanceWorking Public Method

Software Before Code is one of the most mature practitioner expressions of Boundary First Engineering. It treats code as the operational material of a computational representation rather than the entire engineered object.

Next publication gate

External practitioner review, worked cases, and stabilization of the release boundary.

Continue from here
Working public methodOpen Software Before CodeResearch / method contextBoundary First Engineering
More context · 1

The publication is already public as a working method, but working-public status remains distinct from a frozen standard or evidence that the method outperforms established engineering practice in every setting.

Retained record · SOFTWARE BEFORE CODE · BOUNDARY-FIRST ENGINEERING

Determine the object before selecting the mechanism.

Working Public MethodReturn to object

Teams often choose frameworks, schemas, services, APIs, queues, classes, tickets, and deployment structures before agreeing on what the system must preserve. Software Before Code reverses that order.

Same objectDeeper retained representation
Method profile

Code is not the first software artifact.

Software engineering begins with a bounded representation of a domain and a theory of lawful change inside it. State is the information required for lawful continuation; implementation is where that representation becomes executable.

Software is a computational representation of a domain joined to an executable process. Code is the operational material of that representation, not the whole engineered object.
software engineering methodarchitecture doctrinerequirements and modeling disciplineboundary-first engineering practice
  1. 01DOMAIN
  2. 02REPRESENTATION
  3. 03EXECUTABLE TRANSFORMATION
  4. 04DELIVERED ARTIFACT
  5. 05WITNESS / CONSEQUENCE
Representation before mechanism

Most software arguments begin downstream.

Those decisions become brittle when the team has not yet found the distinctions, invariants, and closure conditions the mechanisms are supposed to protect.

Which framework?Which database?Which service boundary?Which queue?Which API shape?Which deployment topology?
Boundary questions

Nine questions before architecture hardens.

Q01

Representation

What world does the system claim to represent, and what does it omit?

Q02

Distinction

Which differences must remain visible, and which may be collapsed?

Q03

Boundary

Where does interaction occur and under what crossing conditions?

Q04

Admissibility

Which states, operations, transitions, and compositions are lawful?

Q05

Invariant

What must remain true?

Q06

Closure

What makes the process complete enough for the domain to recognize, verify, and use?

Q07

Defect

Which forgotten distinction returns as failure, residue, exception, or harm?

Q08

Witness

Who or what verifies the system's claim?

Q09

Consequence

Who receives the gain, cost, risk, or repair burden?

Method

Distinction-to-Closure Software Analysis

  1. 01

    Bound the domain

  2. 02

    Inventory distinctions

  3. 03

    Build the categorical map

  4. 04

    Extract the grammar

  5. 05

    Select representations

  6. 06

    Draw translation and commutation diagrams

  7. 07

    Build the delivery skeleton

  8. 08

    Test closure

  9. 09

    Trace defects upward

  10. 10

    Promote or repair

Representational mechanics

Representation is controlled forgetting.

Every useful software representation makes the world smaller. A database row forgets most of a person. An API response forgets most of a database. A UI forgets implementation. A cache forgets freshness within tolerance. A queue forgets synchronous timing while preserving other semantics.

Forgetting becomes a defect when the system collapses a distinction that execution still needs.

A boundary is a licensed forgetting operator; a defect is the residue of a distinction forgotten without license.

Flagship stress test

Invoice Approval

Build an invoice status tracker.

Naive representation
  • invoice.isApproved: boolean
  • invoice.status: string
Hidden distinctions
  • received
  • syntactically valid
  • vendor recognized
  • goods or services confirmed
  • budget owner approval
  • compliance approval
  • accounting recognition
  • payment authorization
  • scheduled
  • released
  • settled
  • disputed
  • rejected
  • revoked
  • reversed
  • expired
  • duplicate or suspected duplicate
Protected invariants
  • requester cannot satisfy independent approval
  • payment cannot release without authority and evidence
  • reversal preserves original history
  • duplicates cannot independently close without review
  • approved identifies authority, time, policy, and evidence
  • reported success is reconstructable from audit
Binary storage is easy; semantic adequacy is difficult; grammatical validity is consequential; closure is stronger than completion.
Defect diagnosis

Symptoms become useful when they point back to a lost distinction.

SmellLikely defectRepair
boolean proliferationhidden state machineextract states and transitions
status ambiguitydifferent actors mean different thingssplit categorical states and authorities
repeated conditionalsgrammar is dispersedcentralize transition rules
manual spreadsheet reconciliationmissing closure witness or provenancemodel the artifact and repair loop
retry duplicatescommand/event conflationdeclare execution semantics
API success but user failuretechnical and domain closure conflateddefine the domain witness
shared primitive IDscategories collapseduse distinct types
permission checks everywhereauthority boundary not representedmodel capability or role grammar
Closure

Done is a claim. Closure needs a witness.

technical completionsemantic validityinstitutional recognitiondownstream usabilityfailure visibilityrepair ownershipreplay and retry behavioraudit reconstruction
Architecture

Architecture is invariant protection.

Architecture is justified when it protects continuation-sufficient state, consequential distinctions, responsibilities, admissible composition, authority, observability, and repair across execution boundaries. State, transition, persistence, and projection may share one implementation in a small system, but they should not be assumed identical.

AI

AI makes Software Before Code more important, not less.

As implementation becomes cheaper, the cost of choosing the wrong representation becomes proportionally more important. Cheap code increases the value of knowing what the code is supposed to preserve.

Validation ladder

Promotion depends on consequence, not formalism alone.

  1. 01Concept examples
  2. 02Formal toy models
  3. 03Executable reference implementation
  4. 04Comparative design study
  5. 05Legacy archaeology
  6. 06External replication

Compare baseline and Boundary First invoice-approval designs against a 25-fault mutation set and measure detection before deployment.

Formalism is a tool for consequence, not a ritual of sophistication.
Claim firewall

What this method is not.

big design up frontanti-code methodologyframework rejectionformalism for its own sakeclaim of proof of correctness without a bounded proof system