If a human still needs to read every result, decide whether work is complete, find omissions, and arrange each next step after delegating, responsibility for sustained progress and checking results has not yet been fully handed over.
HomoErectus aims for an individual to maintain the connection between objective and result after accepting work: understand requirements, arrange execution and checks, inspect actual artifacts, address problems, and make delivery judgments when evidence is sufficient. Humans primarily participate in important product tradeoffs, scope changes, and other matters that genuinely require their decision.
This document describes the design of that working arrangement. Its reliability and effect on human management effort need validation through actual results, checking evidence, and human intervention.
1. First establish what counts as completion
Checking starts from the objective.
Work needs to specify the desired result, the conditions under which it should hold, constraints, and matters requiring an authorized decision-maker. When requirements are ambiguous, the individual should first check existing materials and context. Remaining questions involving product meaning or significant tradeoffs should be organized into explicit decisions.
The main project distinguishes three sources of delivery requirements.
The first is actual intent and explicit constraints. External commissions need to connect with the real request; autonomous activities need to connect with the individual's own goal source. For example, a readable draft and an already-sent message are different deliverables, as are validation of a local function and of a complete usage path.
The second is professional judgment about the quality needed for this kind of work. A research report needs examination of whether evidence supports its conclusions. A calculation needs checks of field meaning, units, and key results. These requirements need grounds in the task rather than a fixed checklist generated solely from words such as “research” or “report” in a title.
The third is validation conditions in the method being used. If an existing skill requires specific inputs, prerequisite capabilities, and result checks, those conditions need examination during actual use.
Together, these sources form effective delivery requirements. Mandatory contents need to persist through later activity, while advisory improvements remain distinct so that scope does not keep expanding.
2. Connect requirements, artifacts, versions, and evidence
A completion judgment needs answers to specific questions:
| Content | What needs to be explained |
|---|---|
| Requirement | What result and constraints are expected, and where their grounds come from. |
| Artifact | What was actually produced or changed, and where it is located. |
| Version | Which code, file, data, or running instance was checked. |
| Evidence | Which operation or observation supports which requirement, with its results and limitations. |
| Judgment | What is satisfied, what remains unsatisfied, and what happens next. |
For example, a passing code check needs to connect with the code and operating conditions at that time. Later implementation changes require judging whether the earlier evidence still applies. A screenshot from an old version also cannot automatically establish current behavior.
Artifacts and evidence need to be obtainable. A model describing a file does not establish that it was written. A collaborator's test summary needs a connection to original results and their coverage.
These relationships allow the individual to keep answering “what is still missing?” They also let a human find the grounds directly when review is needed instead of reconstructing the entire work history.
3. Choose checks that answer the actual requirements
Different checks support different scopes of conclusion.
Source review helps explain implementation and potential problems. Compilation or format checks identify corresponding structural errors. Local tests examine specific inputs and behavior. Real composed operation is needed to establish how the parts work together along the actual path.
Persistence requirements also need reading after writing. Recovery requirements need evidence of continuation after interruption. Delivery requirements need confirmation that the artifact is viewable at the agreed location or that communication actually reached the relevant state.
Checks should be proportionate to the work.
Research material needs checks of sources, timeliness, conflicts, and the scope of inference. Data results need checks of input meaning, processing rules, and key values. Documents need actual opening or reading of the finished artifact to inspect content and necessary formatting. Code and automation need checks of actual execution, results, and relevant failure conditions according to the objective.
Operation success and objective satisfaction are judged separately. A normal command exit can establish that the run ended, while content evidence is still needed to establish correctness. A file's existence establishes that a file was produced; completeness and usability still require checking.
Work should likewise not always expand into the broadest possible testing. The individual needs checks sufficient to answer current requirements, with coverage stated and genuinely unverified parts retained.
4. How PEOR owns checking and acceptance judgment
Checking results is part of advancing the objective.
When organizing work, the Planner needs to arrange implementation, acquisition, checking, and necessary delivery so each step contributes to the current objective. The Executor performs actual operations, Observation retains returned results, and R/P judges progress against the objective and evidence.
R/P needs to ask which requirements the result satisfies, which obligations remain, whether the evidence is sufficient, and whether further checking, repair, or acquisition is needed or delivery is ready.
Executing every planned step does not establish objective completion. Unsatisfied requirements require appropriate further work or an explicit account of blockage and failure.
Collaboration follows the same relationship. Other agents' results first become observations in the current activity, then are checked against the overall objective. Lower-layer success can support some parent requirements without automatically completing the parent.
An additional reviewing agent can provide another judgment, but its opinion still needs actual artifacts and evidence. If multiple agents say “no problem,” it must still be possible to explain what they checked, which version they used, and whether key requirements were covered.
The runtime can verify explicit conditions such as structure, references, versions, and permissions. Whether content is sufficient, reasoning holds, and results meet professional requirements needs judgment from actual material. A keyword or status field cannot replace it.
5. How work continues after a failed check
A failed check needs to be handled within the corresponding objective.
The individual first investigates whether the failure concerns implementation, misunderstanding, changed input conditions, an unavailable dependency, or a defect in the check itself. It can then acquire information, repair implementation, adjust a local plan, or rearrange checking.
After repair, it needs revalidation against the original requirements and an assessment of whether changes affect existing evidence. Revalidation should cover changes and unresolved questions, avoiding both repeating only the easiest passing parts and endlessly rerunning everything without new grounds.
Checks themselves can need correction. A test may use the wrong input or encode an agreed “greater than” as “greater than or equal to.” The individual can fix such problems while retaining original results, explaining the grounds, and confirming that substantive requirements remain intact.
Changes to product meaning, mandatory scope, or substantive acceptance criteria need the corresponding decision-maker. Removing failed assertions, relaxing requirements, or changing an incorrect result to “pass” cannot complete the work.
Attempts also need boundaries. If reliable progress is unavailable under current conditions, completed work, concrete obstacles, and options should be preserved as an explicit decision need. Work awaiting that decision remains unfinished.
6. How to make accurate and useful delivery judgments
Delivery judgments need both a conclusion and its scope.
An individual can report a passing check or completed part, as well as partial completion, waiting for conditions, inability to verify, or failure. Each conclusion needs actual evidence.
For example, “the local page opens” and “the deployed site is accessible online” are distinct conclusions, as are “a reply draft is ready” and “it was sent to the recipient.” The objective determines the evidence and authorization required.
Work should end when mandatory requirements are satisfied, agreed delivery is complete, and no real obligations remain. Requirements with sufficient evidence do not need duplicate checking, and advisory improvements should not indefinitely prevent delivery.
If an authorized party explicitly changes scope, the grounds need recording and judgment follows the revised requirements. Unresolved substantive requirements remain unfinished rather than disappearing through a rewritten summary.
Humans retaining product direction and important tradeoffs does not mean repeating all technical review. The individual should provide reviewable conclusions, artifacts, and evidence for inspection when needed while continuing to own routine verification, repair, and follow-up.
7. Illustrating acceptance responsibility through HomoErectus development
The following hypothetical scenario illustrates the working arrangement we aim to develop. It is not a record of Adam's actual development work.
Suppose a human confirms a requirement: after interruption, the individual can continue its original unfinished matters without repeating operations that already occurred. The corresponding development, execution, and checking are within the authorized scope.
Adam first needs to understand what must be retained, which actions must not repeat, and what evidence would support those requirements, then arrange implementation, collaboration, and checking.
After a coding agent returns changes, Adam needs to verify the corresponding version, logic, and test results. Local module tests can provide a foundation, but this requirement also needs a real composed path: create a state with unfinished matters, interrupt operation, start a new process, read the original state, and observe subsequent behavior.
If the new process starts but loses the original matters, the requirement remains unsatisfied. If matters persist but completed external operations repeat, repair is still needed.
The failure enters the original activity's checking and reflection. Adam organizes investigation and repair from evidence and revalidates the relevant version. If an external result cannot be reconciled reliably, it needs to state the limitation and judge whether available methods can resolve it.
If the product meaning of when execution may continue must change, Adam should organize known facts, options, and implications for human decision. Ordinary implementation defects and checking arrangements remain for it to handle within its existing scope.
Interim results need the version, cases validated, evidence locations, and uncovered cases. A completion judgment within that scope is justified only when necessary requirements are supported.
The responsibility being handed over includes discovering insufficient evidence and continuing the work, beyond summarizing a coding agent's completion report.
8. How to validate that checking responsibility has actually been taken on
This working role itself needs validation.
First, result quality needs examination: whether delivery meets the original requirements and whether problems were omitted, misreported, or hidden. Proactively finding gaps, handling failures, and obtaining valid evidence after repair are important signs of responsibility in practice.
Second, continuity needs examination: after waiting, collaboration, plan changes, and interruption, does the individual still know which requirements remain unfinished and continue to advance them?
Human management effort also needs observation. Why a human intervened, whether repeated reminders or already-provided background were needed, whether all results had to be reread, and whether the human had to determine each routine next step are worth recording.
Fewer messages alone cannot establish less management effort. Under comparable objectives, quality, and conditions, observation needs to examine review and follow-up effort and whether unfinished work is still left for the human.
Checking experiences should also affect the individual. Repeatedly missing a class of problem should lead to revised self-assessment, learning of checking methods, or changed collaboration arrangements. Effective methods need retained applicability and correct later use.
Our aim is that, after a human explains an objective, the individual can maintain the connection between requirements and evidence, organize work, check results, address gaps, and clearly bring back decisions that genuinely need the human.