# Essai 01 — A small dependency-check commission Date: 18 October 2026. Foray: A useful answer sold by the piece (445). ## Question and bounded result Can one narrow professional output be specified and checked separately, and where does that unit stop being defensible? We constructed a dependency-extract check for a fictional delivery lead preparing a module-release review. The immediate question is which recorded dates should be challenged before test slots are booked. This is one candidate service, not a definition of the whole foray. The executed construction contains six synthetic cases, nine submitted input revisions, nine delivered reports and ten acceptance events (including one replay of an old report). The separate verifier accepts seven complete audits, recognises two correct holds and rejects stale reuse. The ordinary table implementation reaches the same supported conclusions. No buyer, practitioner trial, payment, repeat use or business benefit was observed. These are deliberately selected counterexamples and checks, not a representative sample or preregistered empirical study. They establish what the written acceptance mechanism does on these inputs. They do not estimate market demand, general reliability or actual delivery effort. ## Inputs and purchased result The proposed result is an inspectable report tied to a declared source revision, containing supported findings, explicit holds, evidence references and check coverage. An adverse report can satisfy the service. A clean plan is not a promised output. Every supplied activity has an ID, name, start, finish, predecessor list and source filename. Dates denote exclusive boundaries in a calendar-day model. All supported links are finish-to-start with zero lag: predecessor finish must be less than or equal to successor start. This convention is ours, stated to avoid a hidden inclusive-day/working-calendar choice. Every supported activity has positive duration. Milestones, other link types, working calendars, time zones and leads/lags are outside this unit. The six written checks are: 1. The date, relationship, calendar, finish and authority conventions are declared and supported. 2. Activity identifiers are unique within the governing snapshot. 3. Dates are parseable and activity intervals have positive duration. 4. Each named predecessor exists in the submitted extract. 5. The supplied dependency graph contains no directed cycle. 6. Every evaluable supplied finish-to-start link agrees with the recorded dates. An unresolved convention or authority/identity conflict prevents a complete audit. The report records the hold; date and graph conclusions are withheld. Reporting a hold is correct performance of triage, not completion of the larger audit. Case 03's date format/relationship clarification and case 04's governing-source decision are authored owner responses, not conversations that occurred or truths discovered by the system. No predicate establishes that all necessary work was supplied, that the dates or source statements are true, that resources exist, that durations are realistic, or that release is safe. Case 05's separately held one-bay fact supplies the key counterexample: both audit methods see a passing extract compatible with either one or two test bays. Neither may infer resource feasibility. The sidecar never enters either audit algorithm. ## Actual execution and acceptance `create_cases.py` creates the finite fixtures. `producer.py` produces JSON and readable Markdown reports without accessing expected answers or scenario sidecars. It uses indexed records and a Tarjan strongly-connected-component calculation for cycles. `verify.py` does not import the producer. It reimplements the written predicates with pairwise row scans, explicit date components and a Boolean transitive-closure table. It also checks source hash, ruleset, scope disclaimer, completeness, exact finding/hold sets, evidence references and coverage states. This is the executable ordinary-table comparator and separate acceptance implementation. Implementation independence is limited: both programs were written by the same agent from the same specification. Common specification errors remain possible. The verifier does not independently judge the prose explanations, commercial usefulness, authority of a real source, or a professional's acceptance. “Accepted” in the interface means the written machine predicates passed. No independent professional or buyer acceptance is claimed. A second agent reviewed the source-to-claim boundary in cases 04 and 05: the conflicting-version hold and the clean-dependency/absent-resource distinction were supported. That limited case review is not a professional acceptance trial. Eight deliberate report mutations are rejected: removed adverse findings, unsupported safety claim, incorrect source binding, false completion of ambiguous input, silent choice of a conflicting source, erased evidence, invented defect and claimed execution of withheld checks. A separate stale-report event supplies a changed source and demonstrates rejection plus a fresh valid reissue. These selected challenges are not an error-rate estimate. `tests/check_models.py` additionally compares the two implementations across all 64 loop-free directed graphs on three labelled activities and all six assigned date orders (384 comparisons). Five targeted checks cover a self-loop, invalid date, equality at an exclusive boundary, duplicate identity and unsupported inclusive convention. This checks the implementation on a bounded family; it proves no general professional-service claim. ## Economic exploration All interface minutes, hourly costs, fees, repetition counts and correction rates are editable modelling assumptions. No human performance was timed. Script runtime was not converted to labour time. “Four-minute answer” refers to the default illustrative production allowance, not an observed speed. The scenario includes intake, production, verification, handover, clarification, changed-input rechecks, supplier correction, routine support and setup allocation. The default ordinary and repeatable workflows have identical recurring effort; only assumed setup differs. There is no demonstrated labour advantage. A clarification/recheck allowance is intended to include the associated repeat execution and explanation; adjust it if that interpretation is inadequate. Cost = assumed total minutes × assumed loaded hourly cost / 60. Proposed buyer total = assumed fee × proposed units. The terms allocate zero, one or unlimited changed-input rechecks to the original fee; recheck effort remains in supplier cost in every case. Extra rounds are user-supplied hypothetical changes. Supplier-caused correction never creates another buyer-paid unit. An expected four-minute correction allowance comes from an illustrative 20% × 20 minutes; neither value is measured or a cap on obligation. The “until clear” and unlimited-input offers have no finite maximum obligation in this model. The displayed finite cost is only the scenario shown, not an adequate reserve for unlimited work. Scope expansion to release readiness cannot be priced by these six checks. A positive arithmetic surplus does not establish a viable price, demand, a sale or profit. Loaded cost should cover ordinary overhead; acquisition costs, taxes, financing and exceptional harm are excluded and can materially change the result. ## Reproduction Python 3 standard library is sufficient: ```sh python3 create_cases.py python3 producer.py python3 verify.py python3 tests/check_models.py ``` The published reproduction archive includes inputs, producer, verifier, tests and saved results. The self-contained HTML includes the exact fixture/results record and needs no remote code or fonts. Source inputs and deliveries can be downloaded independently. UI browser checks are retained separately as repository tests; their machine-specific runner paths are not part of the published source package. ## What should follow An independently observed practitioner review could test whether the boundary and evidence are intelligible and adequate. A real buyer trial, if authorised, could test willingness to accept the unit at an explicitly costed price. Neither is replaced by the machine verifier. Other units—judgement, transformation, reviewed recommendation—may expose different boundaries and may properly require an ongoing engagement.