View

Advanced practitioner draft

Closure-Driven Software Development

A Boundary First engineering method for turning uncertainty into executable evidence before unresolved assumptions harden into architecture.

At a glanceAdvanced practitioner draft

The manuscript organizes delivery as progressive closure under uncertainty: discover, bound, build the delivery skeleton, execute, witness, then repair or promote.

Next publication gate

Worked cases, practitioner review, and release editing.

Continue from here
Advanced practitioner draftOpen Closure-Driven Software DevelopmentResearch / method contextBoundary First Engineering
More context · 1

Its current state is explicitly an advanced practitioner draft. The next publication burden is not simply more prose; it is stronger worked cases, external practitioner criticism, and evidence that the method adds clarity without creating process theater.

Advanced practitioner draft · delivery control surface

Turn uncertainty into executable evidence before it hardens into architecture.

Closure-Driven Software DevelopmentReturn to object

A Boundary-First engineering method for progressively tightening domain uncertainty, exposing invariants and responsibility, building the delivery path early, and letting working artifacts correct the plan.

Same engineering methodProgressive-closure instrument
Operating proposition

Delivery is progressive closure under uncertainty.

Backlogs, refinement, prototypes, tests, deployments, and working increments are useful when they reduce consequential uncertainty. The method treats each artifact as a bounded claim about the domain and asks execution to confirm, refine, or falsify that claim.

Own the problem complexity; do not create code complexity.
Closure law

Each artifact is a bounded claim. Execution can confirm it, refine it, or falsify it before the commitment becomes expensive to reverse.

Delivery backplane

A six-stage closure loop.

The loop does not reward activity. Every stage must produce a witness that reduces consequential uncertainty or exposes the need for another pass.

  1. 01

    Discover

    What is the domain actually trying to change, preserve, or recognize?

    Witness · named actors, artifacts, distinctions, and failure cases
  2. 02

    Bound

    What must be true for this increment to be safe enough to commit to implementation?

    Witness · declared scope, invariants, dependencies, and unresolved questions
  3. 03

    Skeleton

    What is the smallest end-to-end path that can expose integration, ownership, environment, and delivery failure?

    Witness · one executable path from real input to recognizable output
  4. 04

    Execute

    What does the working artifact reveal that the plan could not?

    Witness · running behavior, logs, tests, and stakeholder interaction
  5. 05

    Witness

    Who or what can verify that the domain condition was actually satisfied?

    Witness · domain-recognized evidence rather than ticket state alone
  6. 06

    Repair or promote

    Which defects require another loop, and which findings are stable enough to become a stronger commitment?

    Witness · repaired boundary, promoted rule, or explicitly retained uncertainty
Readiness instrument

Implementation readiness is an intersection, not a feeling.

A task is ready when the domain cone of certainty and the executable cone of certainty overlap at the granularity of the commitment being made. The method does not require complete knowledge; it requires enough knowledge for the next irreversible or expensive decision.

Domain coneCan we recognize the right change?
  • the intended outcome is recognizable
  • consequential distinctions are named
  • authority and ownership are visible
  • known failure modes are represented
Commitment windowReady enough for the next irreversible decisionIntersection, not completeness
Executable coneCan the path run, fail, and be repaired?
  • the smallest delivery path is known
  • interfaces and dependencies are reachable
  • the environment can run the increment
  • observation and repair are possible
Executable skeleton

Build the path that can tell the truth.

Establish delivery structure early enough that integration, deployment, ownership, environment, and operational blockers can falsify the plan before large amounts of code accumulate.

  1. 01

    accept one real or representative input

  2. 02

    preserve the distinctions the increment depends on

  3. 03

    perform one meaningful operation

  4. 04

    produce a domain-recognized output or witness

  5. 05

    expose at least one failure path

  6. 06

    include enough observation to diagnose the failure

  7. 07

    identify who can repair the path

Worked delivery loop

Worked example: “Export the current case list.”

A user asks for a CSV export button on a case-management dashboard. The UI request is simple; the domain commitment is not.

Requested surfaceCSV export buttonSimple UI request
Actual commitment9 consequential distinctionsAuthorization · history · ordering · delivery · retention · audit
Hidden distinctionsWhat the button does not tell us
  • D01all cases or only the currently filtered result set
  • D02visible fields versus fields the user is not authorized to export
  • D03current values versus historically reconstructed values
  • D04display labels versus stable machine identifiers
  • D05screen ordering versus deterministic export ordering
  • D06small synchronous exports versus large asynchronous jobs
  • D07successful generation versus successful delivery to the requester
  • D08temporary artifact retention and deletion obligations
  • D09whether the export itself requires an audit record
Smallest executable skeletonEnough path to expose the boundary
  1. 01one authenticated user
  2. 02one representative filtered case set
  3. 03one explicit field-authorization rule
  4. 04one generated file
  5. 05one visible failure state
  6. 06one audit witness linking requester, scope, time, and artifact
Closure gateA file downloading is not sufficient evidence of closure.

The ticket is not closed merely because a file downloads. Closure requires agreement that the exported set is the intended set, protected fields remain protected, the output is reconstructable, failures are visible, and the artifact's lifecycle has an owner.

The working slice is not a miniature final system. It is an instrument for discovering which distinctions the final system must preserve.
Validation console

Treat the method as a testable engineering claim.

Compare a baseline delivery process and a closure-driven process on similarly bounded increments, then inspect whether early executable witnesses reduce late boundary discovery without imposing disproportionate analysis cost.

Evidence targetsWhat would make the method testable?
  • unresolved requirement count at implementation start
  • rework caused by missed domain distinctions
  • escaped defects attributable to representation or boundary errors
  • decision latency for unresolved ownership or authority
  • stakeholder agreement on closure conditions before and after execution
Claim firewall

Draft method, not a universal delivery law.

Safe public standingWhat may be said now
  • Closure-Driven Software Development is a current Boundary First Labs engineering method under active refinement.
  • The method can be evaluated through bounded delivery experiments and comparative project evidence.
  • Its practices intentionally overlap with established Agile, Lean, systems engineering, DevOps, formal methods, domain modeling, testing, and reliability disciplines where those disciplines already solve the problem.
Not establishedWhat remains a validation burden
  • that the method outperforms established software delivery approaches in general
  • that every project should use the same amount of boundary analysis
  • that closure can eliminate uncertainty rather than bound and expose it
  • that a successful worked example constitutes empirical validation