AI workflows · code, examples, and clear limits

AI can get it wrong.
The next step should know.

Runnable AI workflow examples expose their inputs, reasons to continue or stop, and decisions that remain with a person. Source, tests and explicit limits are available for inspection.

Explore the code GitHub profile

7local examples

1command to run the tests

0external actions in the public proof

1human decision at the boundary

Three useful questions

What happens after the AI produces a result?

An answer can look convincing even when a source is missing or out of date. If a message or system change follows automatically, that mistake has a real effect.

Where does it go?

Into an email, a spreadsheet, another tool, or a person's review? The next step tells you what is at stake.

When should it stop?

In the public examples, missing, stale, or conflicting information stops the handoff.

Who decides next?

The test shows why it stopped. A person still reviews any consequential next action.

You can see this in the test examples. If a similar mistake happens in your work, describe one case and we can begin by finding what needs checking.

Ask a question

From example to real question

One failure is enough to begin.

A sanitized description is enough: what enters the system, where the result goes, and which mistake causes the most trouble. The first conversation needs no credentials, private files, or production access.

Then we can define a small check: a valid example passes, broken ones stop with a reason. Any real work needs its own scope and agreement.

The public code uses synthetic data. It is not a client deployment and performs no external action.

What is in the code

One handoff has three parts you can inspect.

Source and next step

What the program receives, where it sends a result, and who owns the decision.

A clear stop

When information is missing, stale, or contradictory, the workflow does not pretend it succeeded.

Tests and limits

Valid and broken cases, a reason for each result, and a plain account of what the tests do not prove.

Start with something concrete

Understand one handoff first.

A small example shows where a workflow can go wrong. Only then is it useful to talk about a larger system.

01 · first question
One handoff

Can one handoff accept a valid example and clearly refuse the bad ones?
02 · if the evidence calls for it
Nearby steps

The first result may show whether other transitions need attention.
03 · if more work is useful
What remains

After that, we can describe the open questions. A description alone does not authorize changes to a working system.

Technical detailMap the path from evidence to human review

Operating Core Map

See where the decision changes hands.

This interactive map follows one example from input to evidence check, bounded work and human review. It is a way to inspect the idea, not a running client system.

Checked-in control-surface map

System boundary

Stage: system-boundary
Public reference: Typed source-to-target boundary
For a real workflow: Named source, target, owner, and schema
Not claimed: No client-system access or production.
Authority: none
External action authorized: false
Production: false
Provider observed: false

Browser-local inspection of a checked-in map, not a runtime system, evidence, contract, deployment, provider observation, or permission. It has no network, storage, telemetry, clipboard, navigation, prefill, or submit APIs.

Public, runnable evidence

Run the examples and inspect the method.

The repository contains dependency-free references for evidence gates, bounded asynchronous polling, operator handoff, and explicit terminal failure states. One command runs this demo's test suite; it is not a safety guarantee for a future client adapter.

python3 run_proof.py

Try it yourself

Change the evidence. See the decision.

Choose a test scenario. The example shows a decision and its reason without taking any external action.

Checked-in synthetic outcome

Valid evidence

Triage outcome: draft
Named reason: EVIDENCE_COMPLETE
Fixture decision: draft
External action authorized: false

Complete synthetic evidence can produce a draft; a human still decides any next action.

Prepared test data, not an assessment of your system. This example runs only in this tab.

Method and technical limits

Illustrative browser-local replay of the separate checked-in evidence-gate fixtures. The current checked-in explorer source contains no network, storage, or telemetry APIs. It is not Python equivalence, EGOH parity, production safety, certification, client validity, or external authorization.

Optional planning toolBreak down one workflow before getting in touch

Local acceptance packet

Build a narrow review-only draft before a public inquiry.

Choose controlled values only. The builder produces a browser-local planning draft, not evidence, a contract, an award, a payment, or authority for an external action.

1 · Handoff type

2 · Buyer-declared source category

3 · Narrow target

4 · Decision owner role

5 · Costly failure that must fail closed

6 · What would show it works?

7 · Test environment

8 · Human action boundary

9 · Public boundary declaration

Your browser-local output

Review-only planning draft

{
  "schema": "external-buyer-acceptance-packet-v1",
  "workflow": null,
  "source": null,
  "target": null,
  "decision_owner_role": null,
  "decision_owner_status": "must-be-named-during-human-review",
  "costly_failure": null,
  "measurable_five_day_evidence": null,
  "test_environment": null,
  "human_action_boundary": null,
  "boundary_declaration": null,
  "exclusions": "production-credentials-private-data-payment-account-changes-excluded",
  "output_status": "UNSENT · no buyer selections · local to this tab · not validated",
  "scope": "review-only",
  "draft_class": "unpopulated-planning-template",
  "completion_status": "incomplete",
  "authority": "none",
  "evidence": false,
  "contract": false,
  "award": false,
  "payment": false,
  "external_action": false,
  "external_action_authorized": false,
  "production": false,
  "production_activation": "excluded",
  "automatic_submit": false,
  "manual_route": "existing-github-issue-form"
}

Canonical Issue Form bridge

Local check first, then a manual public summary.

{
  "state": "held-incomplete-local-draft",
  "authority": "none",
  "external_action_authorized": false
}

After every controlled value is chosen, the bridge shows the engineering scaffold plus the buyer-declared acquisition-source choice for the canonical Issue Form. Review every public summary manually: this page does not enter, copy, or submit it. Then manually open the existing English public GitHub Issue Form. A public form cannot verify the absence of private data.

Manually open the existing English public GitHub Issue Form

Do not enter here or add to a public issue any secrets, credentials, private code, customer/personal data, private URLs, or production access details. The current builder has controlled fields and no network, storage, telemetry, or automatic-submit APIs.

Where this helps

When an AI answer becomes someone's action.

For example, a program passes a result to another tool, waits for a service, or decides whether its sources are enough for a conclusion.

If we cannot make an honest check, that is also a result: name what is missing instead of calling an unknown outcome a success.

Have a question or a similar problem?

Describe one case. We can start there.

Ask a question GitHub profile

Public issues are visible to everyone. Do not send passwords, private data, client code, or production access details.