Examples / A closer look
Follow a concrete case and see what happens when a source, a decision or a confirmation is missing. Controls around AI help people retain oversight and responsibility.
A late truck. A pallet not yet scanned. What can actually be promised?
Explore the example → 02 / Start hereFrom the first hypothesis to an authorised remedy and checked recovery.
Explore the example → 03 / Start hereSee how an old policy can produce a clear but incorrect answer.
Explore the example →Illustrative scenarios, not completed customer engagements. The exercises use authored rules in your browser. They run no AI model, send no data and change no real systems.
Two terminal scenarios
Follow the evidence, the human decision and the confirmation required before the next step.
Prepare a revised unloading plan for Truck T17, consignment C204. The booked Dock 4 slot starts at 06:45; do not change a live booking without the required decision.
Dock 2 remains a proposed alternative. Keep the request pending and tell the driver that confirmation is awaited.
The supervisor requests options for unloading C204. The task is to prepare a plan; the operating team owns live booking decisions. The planning agent creates a bounded case and records the requested output, action boundary and current sources.
The booking source says Dock 4, 06:45-07:00. The driver update says ETA 06:58. The current handling plan requires 20 minutes for unloading. The agent checks that the booking, vehicle and driver message refer to the same consignment. It reads the local dock rules instead of a generic national example.
The agent's initial proposal is 'keep the booking because Dock 4 is already assigned'. A new arrival estimate makes that proposal impractical within the present slot. The case records the proposal as an interpretation and identifies its unsupported assumption: assigned does not mean currently feasible.
Operations identifies a later Dock 4 slot at 07:20 and a possible Dock 2 slot at 07:05. Neither option is yet accepted for this delivery. The agent revisits H0 using the new information. It refines both alternatives: wait for Dock 4's later slot, or request Dock 2 if availability is confirmed. The inquiry now concerns conditional options rather than defending the old booking.
The supervisor selects the Dock 2 alternative within the applicable authority and sends a correlated booking request. The agent records the decision and request identity. 'Request received' is kept separate from 'slot accepted'. A timeout leads to a request-status check before any retry.
The last handoff needs the actual booking response. The driver must receive the terminal's accepted time, not merely the agent's preferred option. Inspect the confirming record for consignment, dock and time. Use the condition below to see why receipt of that evidence changes the permitted status statement.
Measure in a pilot: unsupported completion claims, time to confirmation and duplicate requests.
Prepare the loading-readiness status for consignment C318. The manifest lists twelve pallets, while the dock feed contains eleven matching current scans.
The current record supports eleven verified scans and one unresolved pallet. Keep the loading-readiness check pending.
The shift supervisor asks whether C318 is ready at the dock. The manifest and dock scan feed answer different parts of that question. The agent defines the expected output: a status based on matching current consignment events, with missing observations named.
A historical return record also uses local label P12. Its existence could make a simple label match appear complete. The agent checks consignment identity, event type and time before using the P12 record as evidence for this load.
The first interpretation says the feed is probably delayed because the manifest is complete. The current scan count still supports only eleven observed pallets. The agent separates the observed count from the delayed-feed hypothesis and the alternative that the pallet is still in staging.
A newer staging event places the twelfth pallet in zone B. The complete manifest no longer supports assuming that all pallets have reached the dock. The agent reinterprets 'complete' as manifest completeness, not observed dock readiness. It refines the open question to a concrete current movement and scan check.
Warehouse operations receives a request to confirm the pallet's current state using the consignment-specific identifier. The request names the pallet, consignment, expected observation and return surface. Acknowledgment does not close the physical check.
The final status depends on whether the requested current observation arrived and matches the expected consignment. Apply the returned observation to the original readiness requirement, then communicate the bounded status and retain any pending follow-up.
Measure in a pilot: unsupported completion claims, time to confirmation and duplicate requests.
Try one control at a time
Change the controls and compare the outcome. All values and decisions are fictional teaching examples.
An old returns policy says 14 days. The current policy says 30 days.
Without a revision check, the first source can give the old answer: 14 days.
The task is to prepare three campaign options. Publication needs a separate decision.
Publication is held until the required decision exists.
Returns must be accepted up to and including day 30. The faulty rule uses less than 30.
Day 10 passes even with the defect. The day-30 boundary case exposes it.
Each attempt costs four invented units and adds no new evidence.
A budget of 10 covers two attempts. The third must wait. Units are not real prices.
The draft is ready, but its review has not been completed.
A finished draft is not a publication decision. Check the pending review.
An export job has run. The recipient also needs the correct file, schema and content.
Requested, executed and outcome-checked are three different states.
Each handover needs a clear output, an owner and a condition for the next step.
Read the event, identify its consignment and record the source time. Separate a proposed arrival time from a confirmed terminal booking.
Checkpoint: The event can be associated with the right consignment; ambiguous matches remain open.
Read the applicable dock, timing and action constraints. Check the actual booking window and the conditions needed for a useful alternative.
Checkpoint: The sources apply to this terminal, shift and operational question.
Use DIALECTIC to compare the present explanation with the conflicting evidence. Refine alternatives and ask the smallest discriminating question.
Checkpoint: No option is called feasible merely because it sounds plausible; its necessary conditions are explicit.
Present the options, record the decision and issue the exact bounded request. Correlate the returned acceptance or rejection with that request.
Checkpoint: The actor has authority for the particular action; acknowledgment and acceptance remain distinct.
Check the dock, time window and consignment against the decision. Produce the driver update and a concise handover with any remaining work.
Checkpoint: A confirming record supports the status communicated to the driver or next shift.
Group the observations into a bounded incident. Keep the measured symptom separate from an explanation of its cause.
Checkpoint: The team knows which service and environment the signals concern.
Read the applicable configuration and deployment evidence. Distinguish a checked-in change from the version actually running.
Checkpoint: The material applies to the affected environment and time window.
Compare the release hypothesis with regional, dependency and timing evidence. Select a bounded check that can distinguish the alternatives.
Checkpoint: The chosen check is within scope and can change the assessment.
Prepare the bounded correction and preserve the displaced configuration. Execute only the approved change through the applicable operating path.
Checkpoint: The authorized action, target environment and recovery route are explicit.
Observe whether the relevant service behavior recovered. Retain residual symptoms, a shift handover and a bounded learning record.
Checkpoint: A successful command is accompanied by the required service observation.
Identify the source set, the reader's prerequisites and the material's promised outcome. Reuse existing useful parts before creating new sections.
Checkpoint: The scope and reader promise can be checked against actual source material.
Check API, version and capability claims against their owner sources. Separate dated facts, examples, interpretations and unsupported assertions.
Checkpoint: Each consequential reader promise has adequate support or is revised before use.
Address structural problems first, then specific accuracy and teaching gaps. Keep the edit history connected to the finding each change addresses.
Checkpoint: The correction meets its closure criterion and relevant neighboring requirements are checked.
Render the actual delivered format, inspect the layout and try the offered example using the supplied instructions.
Checkpoint: The offered link, download or exercise works in its stated scope.
Review the disclosure boundary, obtain the relevant release decision and pass the exact artifact to the publishing owner. Retain source and revision links.
Checkpoint: Content readiness and public-release authority are both satisfied before public disclosure.
Preserve what was observed and its context. Keep a suggested explanation separate from the event itself.
Checkpoint: The capture says what was actually observed and where its context can be found.
Check whether the new record concerns an existing subject, another representation of it or a materially different case.
Checkpoint: A similar title alone is not used to merge two subjects.
Distill the reusable point and classify time, interpretation and content type. Separate the completed action from the proposed explanation or future task.
Checkpoint: The summary preserves material qualifications and the source route.
Review the claim and place it on the appropriate surface. Add orientation and relations without copying the entire source into every consumer.
Checkpoint: The record fits the target's schema and claims only what its evidence supports.
Bring the record into the task's orientation and check whether it still applies. Reuse its lesson without silently inheriting old permissions.
Checkpoint: Relevance is checked against this consumer, source version and action class.
Choose the smallest useful explanation and a representative scenario. Identify which underlying claims are already public and which remain private.
Checkpoint: The example teaches a real mechanism without requiring private implementation details.
Check all bytes intended for the public artifact, including embedded data. Confirm the source support and the applicable public admission.
Checkpoint: Public branches and PRs are treated as disclosure surfaces, so admission precedes them.
Create the explanation and local interaction using public-safe, illustrative data. Integrate with existing design rather than creating a competing site system.
Checkpoint: Private source code, operational data and secrets are absent from the delivered artifact.
Check behavior, reading routes, layout and preservation on the exact revision intended for integration.
Checkpoint: A prior green result is not reused for an unreviewed later revision.
Integrate through the applicable branch and PR routine, preserve history and check the resulting delivery surface.
Checkpoint: Merge, deployment and live availability are recorded as distinct outcomes.
Identify the actual source versions and the purpose of the piece. Separate provided assets, proposed additions and the constraints on their use.
Checkpoint: The required source material and applicable usage scope are clear.
Map the material to sections, shots or processing stages. Define intermediate artifacts and the checks needed before assembling them.
Checkpoint: The plan can be carried out within the requested scope and resources.
Produce the selected assets and retain each result with its source and attempt identity. Review significant mismatches before spending further attempts.
Checkpoint: Each selected asset meets its declared local requirement before downstream assembly.
Assemble the sequence and export the requested format. Retain the source-to-output mapping needed for later changes.
Checkpoint: The artifact corresponds to the selected inputs and the intended sequence.
Check the delivered artifact for timing, continuity, readable credits and format behavior. Record acceptance or the next bounded correction.
Checkpoint: The final exported artifact, rather than only the editor preview, has been inspected.
Thirty examples show where a particular control can help. Suggested measures are pilot questions, not measured customer results.
30 examples
Further reading: DIALECTIC
Further reading: DIALECTIC
Further reading: SORR
Further reading: SORR
Further reading: ORBIT
Further reading: ORBIT
Further reading: CARD
Further reading: CARD
Further reading: POINTER
Further reading: POINTER
Further reading: 5 Point Protocol
Further reading: 5 Point Protocol
Further reading: Dialogue Lifecycle
Further reading: Dialogue Lifecycle
Further reading: RigVedan / EBNF-RV
Further reading: RigVedan / EBNF-RV
Further reading: Layered context
Further reading: Layered context
Further reading: Review-edit-verify
Further reading: Review-edit-verify
Further reading: Technology verification ledger
Further reading: Technology verification ledger
Further reading: Structured continuity
Further reading: Structured continuity
Further reading: Budget, retry & stop controls
Further reading: Budget, retry & stop controls
Further reading: Provenance & outcome evidence
Further reading: Provenance & outcome evidence
Further reading: Brief, return & ownership contracts
Further reading: Brief, return & ownership contracts
No examples match. Try another word or choose all controls.
These are the controls around the model: which sources it may use, which tools it may call, when a human decision is needed and how the outcome is checked. A practical solution combines only the controls the task needs.
Adapted from Fredrik Brattén’s Harnessing Library: scenarios, method examples and control exercises. The material is illustrative and is not evidence of a deployed Farbar service. Read the full library.
From an example to your work
We start with the situation, the responsible person and a measurable next step.
