Holdex
Holdex Moves a Supported Task From Input to an Observable Result
Holdex moves a supported product task from an agreed business outcome into a small, reviewable change. The first input is not a preferred stack. It is a clear statement of what a user should be able to do, what blocks that outcome, and what observable behavior will count as success. That intent becomes a versioned specification, while implementation travels through a focused pull request. As behavior ships, the matching material moves into current documentation. The task reaches its exit boundary when the change is visible, the acceptance condition can be checked, and the record no longer treats delivered behavior as pending.
Jump to a section
Bottom line: A supported task is complete when its observable behavior matches the agreed condition and its record no longer describes that behavior as pending.
Supported Inputs and Their Working States
An incoming task can begin as an outcome from discovery, a blocker in an existing product, or material from an external planning document. These inputs can inform the task, but they do not replace the versioned specification. Recordings, notes, and design references feed the task, while the versioned specification states the behavior that has not shipped.
Existing behavior needs a different treatment. Current documentation describes what is already available, so it cannot be used as a wish list. If the requested capability is absent, the gap becomes unimplemented scope. If it already exists, the work may instead involve verification, correction, or documentation reconciliation.
That split prevents a second solution from being built for a capability that is already present. It also stops planned behavior from being mistaken for a finished feature.
Prerequisites Before the First Change
The prerequisite state includes the current behavior, the permitted environment, necessary access, and any dependency that can block the change. The active configuration determines which action is available. A task touching a digital-asset flow should also identify the relevant authority, the state being changed, and whether the action crosses a production commitment boundary. Acceptance must be observable before implementation begins, such as a user action completing, a system record changing, or an expected failure appearing under the defined condition.
How Does One Task Become a Buildable Unit?
One task becomes buildable when a broad Goal is reduced to a specific Problem with a proposed Solution. The Goal carries the business aim and timing. The Problem names the obstacle between the present state and that aim. The Solution is a focused pull request that changes one bounded piece of behavior.
Holdex records intended user actions and observable outcomes in one specification written in business language for founders and engineers. Using one specification reduces misunderstandings between the person defining the outcome and the people implementing it. It also gives review a stable question: does the change deliver the behavior described in the still-open section?
A workable unit names the starting state, allowed action, intended state change, and proof of completion. It also identifies conditions that would stop the work. Those boundaries matter when implementation depends on permissions, external systems, design approval, or a production environment that is not yet available.
The Commitment Boundary
A commitment boundary marks the point where a proposed change affects shared or production state. Reviewable code, design material, and a test deployment can often be changed without affecting live users. A production deployment, permission change, smart-contract interaction, or settlement-related operation may carry a different reversal cost and authority requirement.
Work before that boundary should produce enough evidence to decide whether the live action is justified. The smallest supported change is preferable because its effect can be isolated, reviewed, and compared with the acceptance condition. If the active configuration does not permit the intended operation, the task stops at that constraint instead of substituting a different action.
Unclear authority is also a blocker. A technically possible action does not become part of the task until its environment, owner, and expected state change are explicit.
From Pull Request to Observable Change
A pull request carries the selected solution and connects the code or document change to its Problem. Review should compare the proposed behavior with the specification, inspect the relevant configuration, and test the observable condition. Passing review means the bounded change is acceptable for its stated purpose, not that every surrounding feature has been reassessed.
When a pull request delivers part of a Goal, its corresponding material moves from the unshipped specification into current documentation. The specification therefore shrinks as implementation advances, while the documentation describes behavior that readers can expect to find now.
Design references move with the behavioral material when they define the delivered interface. The pull request history then connects intent, implementation, review, and documentation. If the observed state does not match the acceptance condition, the section remains pending or a bounded correction is opened. Renaming the output or updating documentation alone cannot repair a failed state change.
One Requirement in Two States
Consider a requirement that a defined user action must produce a recorded status change. The requirement is functional; no asset, network, or live value is assumed. Its treatment depends on whether the capability is pending or already present.
Two Starting Records
Behavior Not Yet Shipped
When the behavior is absent, its specification section states the intended action, permitted configuration, expected record change, and acceptance condition. The smallest safe action is a focused implementation that can be reviewed before production. Evidence is the observed change in the agreed environment, followed by documentation that describes the delivered behavior.
Behavior Already Present
When the behavior already exists, new implementation is not the first move. Compare current documentation, actual state, and the task request on the same dimensions: allowed action, changed record, and success condition. If they agree, verification may close the task. If they diverge, open a bounded correction instead of recreating the capability.
Acceptance Decision Checklist
Use these conditions at the decision point:
- Name the user or operator action without prescribing an unsupported implementation.
- Place pending behavior in the specification and shipped behavior in current documentation.
- Confirm that the chosen action is allowed by the active configuration and environment.
- Identify the record, event, or visible state that should change.
- Stop only when the observed state matches the agreed condition and the records agree.
Both branches examine the same evidence. Their difference is whether work should alter behavior or reconcile proof of behavior that already exists.
What Happens When Scope Changes Mid-Task?
A scope change returns to the unshipped specification before implementation continues. The new material should state the added or altered behavior, its constraint, and the evidence that will distinguish completion from partial progress.
A change to already shipped behavior also begins as new unshipped intent. Current documentation keeps describing the live state until a reviewed change replaces it.
Added scope may remain under the same Goal when it serves the same business outcome, but it should not disappear inside an unrelated pull request. A separate Problem and Solution preserve the reason for the change and keep review bounded.
Removed scope follows the opposite path. The unused section leaves the specification without being presented as delivered behavior. That distinction keeps cancellation, implementation, and documentation from collapsing into the same status.
Exit Evidence and Recorded Handoff
Exit evidence connects the agreed condition to an observed state. The relevant proof may be user-visible behavior, a system record, a test result, or a state transition in the agreed environment. Its form follows the task; the evidence should not claim more than the bounded action demonstrates.
The task can close when no agreed behavior remains pending, the delivered sections appear in current documentation, and the recorded outcome matches the original condition. Open dependencies, unresolved review comments, or a mismatch between displayed success and underlying state keep the task inside its stop boundary.
A documented handoff preserves the reason for the change, the implemented behavior, and the evidence used for acceptance. An informal handoff leaves the next reviewer to reconstruct all three from messages and memory.
Details worth knowing about Holdex
Which Record Should Be Trusted When a Specification and Current Documentation Disagree?
Current documentation should describe shipped behavior, while the specification should contain only behavior that remains unimplemented. If those records disagree, inspect the implemented state and pull request history, then reconcile both files. Do not treat either document as correct merely because it is newer; its assigned role and the observable product state determine what belongs there.
Can a Design File Replace a Written Acceptance Condition?
No. A design reference can establish appearance, interaction intent, or layout, but it does not replace a written statement of user behavior and observable success. Holdex places design material inside the specification so it travels with the relevant behavior. Acceptance should compare both when visual and functional requirements belong to the same bounded task.
Is an External Planning Document Enough to Open a Delivery Goal?
No. External notes or a collaborative document can feed discovery, but the agreed behavior should move into the versioned specification before the Goal opens. The external link may remain part of the surrounding record. It should not become a second specification whose wording can drift away from implementation and review.
Does an Empty Specification Prove the Whole Product Is Ready for Production?
No. An empty unshipped specification means the defined Goal’s sections have either graduated into current documentation or been removed from scope. It does not prove that the entire product is secure, compliant, scalable, or ready for every production use. Those claims need their own acceptance conditions and evidence.
What Evidence Confirms a Digital-Asset State Change?
Evidence should mirror the state change named in the task. For an onchain action, that may be the expected transaction status, emitted event, or contract state in the agreed environment. For an offchain operation, it may be a reconciled system record. A success message is insufficient when it can appear before the underlying state changes.
Who Decides Whether the Acceptance Condition Has Been Satisfied?
The stakeholder responsible for the product outcome should confirm whether the observable condition matches what was agreed during discovery. Engineers can show the implementation, tests, and resulting state, but they should not silently redefine success around what was easiest to build. A disputed outcome keeps the task open until the condition is clarified or the scope is formally changed.