Connect the workflow.
Bring a company Owner, one supported source and the separately approved original financial owner.
Check the preparation →Payment control for AI agents
Connect your agents.
Keep payment authority intact.
Start with one Sandbox workflow. Connect the original approval, assign the work and verify what stays under your company’s control when the Agent changes.
Workspace + supported Sandbox profiles · Separate Python + JavaScript/TypeScript SDK exercises · No real funds
The free diagnostic Lab below reviews records and decision code. It is a separate tool from the Payment API evaluator.
ONE WORKFLOW. THE SAME ORIGINAL.
A clear path from setup to evidence.
The company retains the original approval and history. Each Agent receives only its assigned work; execution requires the installed financial boundary.
Hand off the work.
Enroll distinct Agent keys, verify the receiving proof and transfer the assignment without creating another right to pay.
Follow the handoff →Verify the boundary.
Review the exact installed host, retained state, controlled paths and recovery evidence with the responsible owners.
Review installed execution →Start with the free Workspace example. Your own Agent enrollment and execution host require their supported setup; a verified review or draft is not a financial grant.
Separate developer path: the public SDK fixtures exercise the local Payment API contract. Installing a client does not connect the Workspace Agent runtime or activate payment control.
PUBLIC SDKs · SYNTHETIC EVALUATION
See the recovery contract run.
Recover the original. Hold an uncertain replacement. Refuse another payment after the obligation is paid. Run the published clients against fixed HTTP fixtures and keep the result.
Published on PyPI
Python
0.2.0rc2 · Python 3.12+
Install the pinned package, then run recovery from your terminal.
Run the Python quickstartGitHub release
JavaScript / TypeScript
0.2.0-rc.2 · Node 22+
Install the release file. npm registry publication is pending.
Run the JavaScript quickstartNo installation
Browser
Free recovery exercise
Follow the six-step fixture flow and download its synthetic record.
Try payment recoveryNo HALTSEAL account, provider credentials or real funds. Installation supplies an evaluation client; it does not connect a bank or activate payment control.
Read the Payment API reference for signed obligations, exact attempts and configured local evaluation. HALTSEAL/payments-sdk on GitHub (opens in a new tab) includes the client sources, recovery examples and versioned releases. The payment kernel remains separately scoped.
Google ADK · Runnable source example
A new agent.
The same payment identity.
Repeat calls and an agent/session handoff retain the trusted host’s obligation, operation and approval. Model arguments cannot replace those bindings.
ADK 2.11.0 · Python SDK 0.2.0rc2 · 8 boundary guards passed
Observed in fixed local fixtures
- Original unresolved
- HOLD
- Closure + fresh approval
- ACCEPT
- Obligation paid
- REFUSE
Closure alone keeps the old approval on HOLD. The fixture defines an immediately paid replacement winner.
Run the ADK example (opens in a new tab)View verification results (opens in a new tab)Evaluate your workflow
Real ADK runtime · scripted model · loopback fixtures. Host state is in memory; customer, native-provider and production qualification remain separate.
INSTALLED WORKFLOW KIT
Keep recovery on the same original.
The Linux kit groups the reviewed runtime, application adapter and reporting entrypoints for one Sandbox workflow. A lost reply resolves the retained attempt; a reinstall preserves its history.
Begin with a current Workspace Owner, one workflow and the public key generated on the execution host. Agree the approval source, both software release points and the evidence your team will review before installation.
Install the reviewed code.
Verify the package against independently obtained release pins and bind the host to the selected company and workflow.
Exercise the recovery path.
Check UNKNOWN reservation, replacement HOLD, exact-original recovery and same-release reinstall in the agreed test environment.
Review the retained record.
Compare the installed report and authority evidence for the same original and checkpoint. A report is an observation, not a payment grant.
Current native reference: one Linux execution host, fictional own-account USD 10 and two Increase Sandbox paths. Customer installation and the deployed Workspace journey require separate acceptance. The independent remote-control profile has separate qualification evidence.
Payment Control Lab · See the output before you run
Same obligation.
Three different conclusions.
Open real reports generated by the released Lab from three synthetic traces. No installation or account is needed to inspect them.
Synthetic trace · v0.2.0Control gap observed
Lost response, released backup
CONTROL_GAP_OBSERVED
Recorded sequence
- decisionACCEPT recorded for attempt-a via processor-a.
- releaseRelease recorded for attempt-a via processor-a.
- outcomeunknown recorded for attempt-a.
- decisionACCEPT recorded for attempt-b via processor-b.
- releaseRelease recorded for attempt-b via processor-b.
Finding / evidence
A replacement is accepted while an earlier attempt for this obligation remains unresolved.
Keep the replacement on hold until reliable closure evidence is obtained, then validate the exact replacement again.
- Mapped obligation
- 1
- Declared paths
- 3
- Supplied events
- 5
Findings apply to supplied records and declared paths. Mapping and coverage are operator assertions. Release records do not prove duplicated monetary effects; no finding does not establish production protection.
Synthetic trace · v0.2.0No finding in this trace
Lost response, held backup
NO_FINDING_IN_TRACE
Recorded sequence
- decisionACCEPT recorded for attempt-a via processor-a.
- releaseRelease recorded for attempt-a via processor-a.
- outcomeunknown recorded for attempt-a.
- decisionHOLD recorded for attempt-b via processor-b.
Finding / evidence
No supported finding within these supplied records.
Keep the declared paths, obligation mapping, and evidence limits attached to this result.
- Mapped obligation
- 1
- Declared paths
- 3
- Supplied events
- 4
Findings apply to supplied records and declared paths. Mapping and coverage are operator assertions. Release records do not prove duplicated monetary effects; no finding does not establish production protection.
Synthetic trace · v0.2.0Inconclusive
Manual bank portal not observed
INCONCLUSIVE
Recorded sequence
- decisionACCEPT recorded for attempt-a via processor-a.
- releaseRelease recorded for attempt-a via processor-a.
- outcomeunknown recorded for attempt-a.
- decisionHOLD recorded for attempt-b via processor-b.
Finding / evidence
No execution records are supplied for Manual bank portal.
Obtain redacted records or document how this path is governed before concluding coverage.
- Mapped obligation
- 1
- Declared paths
- 3
- Supplied events
- 4
Findings apply to supplied records and declared paths. Mapping and coverage are operator assertions. Release records do not prove duplicated monetary effects; no finding does not establish production protection.
These are authored examples, not customer incidents. The downloadable owner summary is the original Lab output. The synthetic input and complete JSON remain attached. All sixteen examples remain available in the local demo.
Why these cases matter. Understand the payment workflow
Start from a checkout
Start with the released Lab.
No account is needed to run the local tool. Use the versioned Release so your team checks the same source.
git clone --branch v0.2.0 --depth 1 https://github.com/HALTSEAL/payment-control-lab.git
cd payment-control-lab
python lab.py demoUse python3 on macOS/Linux or py on Windows if needed. Open out/demo/report.html or out/demo/owner-summary.html. Demo success means the sixteen authored diagnoses were reproduced.
What do you have?
Payment recordsMap one obligation and review its event history.Decision codeConnect your existing rule and inspect its decisions.Both routes produce report.html, report.json and owner-summary.html.
Apply it to one workflow
Start with what your team has.
Use the record review for event history. Use the code check for a trusted local decision function. Keep their evidence and conclusions distinct.
Review the original and backup.
From the Lab checkout, create a local input file.
python lab.py template --out workflow.jsonEdit workflow.json locally. Use one obligation alias across its original and replacement paths. Declare unobserved paths and preserve unknown outcomes.
See how two paths share one obligation
In the released example, both actions refer to the same mapped obligation:
| Field | Original | Backup |
|---|---|---|
| obligation_id | invoice-001 | invoice-001 |
| attempt_id | attempt-a | attempt-b |
| route_id | processor-a | processor-b |
Matching amounts or payees alone do not establish the same obligation. The Lab uses your mapping; it cannot discover a hidden match or automatically redact your records.
Download the complete synthetic inputpython lab.py review workflow.json --out out/my-workflowOpen out/my-workflow/owner-summary.html first. Keep its report.html and report.json alongside it.
Use permitted, redacted records. No credentials, account numbers, personal identifiers or full provider responses. Local review does not upload the file.
Read the input contract (opens in a new tab)Check the rule your application uses.
Copy the customer adapter (opens in a new tab) into your application repository as payment_policy_adapter.py. Bind it to your existing decision logic, mock dependencies and map its result to ACCEPT, HOLD or REFUSE.
Inspect the supplied context
- proposal / obligation
- The exact proposed action and mapped payment obligation.
- prior_attempts
- Earlier outcomes and their asserted finality and evidence origin.
- declared_coverage_complete
- Whether the declared fixture paths are represented.
- approval_matches_proposal / fresh_decision
- Whether approval binds this proposal and fresh validation is established.
These are synthetic assumptions, not authenticated provider evidence. Your wrapper must call the code under review. The unbound adapter returns an inconclusive result.
From your application root, replace /path/to/payment-control-lab with your Lab checkout path, then run:
python /path/to/payment-control-lab/lab.py check-policy payment_policy_adapter:decide --ci-mode report --out out/payment-controlOpen out/payment-control/owner-summary.html. Advisory exit 0 means the diagnostic completed; inspect its verdict and unknowns.
Only use trusted, fast, side-effect-free code with mocked dependencies. Callbacks are not sandboxed. No payment execution functions or production credentials.
Compare a change and retain it in CI
Supply wrappers for both code versions with isolated state. The Lab does not fetch the earlier version for you.
python /path/to/payment-control-lab/lab.py compare-policy payment_policy_before:decide payment_policy_after:decide --ci-mode report --out out/payment-changeOpen out/payment-change/report.html. Agree the fixture contract and review owner before enabling gate mode. The optional CI template uploads reports to GitHub; agree access and retention first.
Adapter and CI guide (opens in a new tab)Trace review reports CONTROL_GAP_OBSERVED, NO_FINDING_IN_TRACE or INCONCLUSIVE. Code checks report whether the authored expectations matched. Neither establishes live payment protection.
Before the first run
Verify the files you run.
Download the source ZIP, wheel, manifest and SHA256SUMS together. Compare the manifest digest with the trusted Release record, then verify the package before installation.
# From the trusted source checkout.
python tools/verify_release.py /path/to/downloaded-release \
--expected-manifest-sha256 6d9950b4d8ee1674f624751090aad9f4b0dea68b3355f74ebb3856a2d5d3edcb --installThe command uses the manifest digest from the v0.2.0 Release. Verification checks file integrity, source matching and the installed diagnostics. It does not establish production payment protection. Use --install only for a trusted release; it runs the diagnostic code in a fresh virtual environment.
From diagnostics to an integration
One workflow.
A defined next step.
Follow the Agent connection guide to prepare your source, original approval, enrolled Agents and installed scope. Bring the diagnostic findings to the responsible owners. Optional assistance is separately agreed; operating qualification remains specific to the workflow.
Bring three things.
- The payment workflow and obligation.
- The original path and every known replacement path, including manual portals.
- The decision owner and the timing of the next decision.
Use a non-confidential description for the first inquiry. No credentials or raw payment records. Assessment may lead to Shadow with no payment authority; enforcement needs technical validation and customer approval.
Diagnostic scope. The lab checks authored synthetic expectations and supplied records. It does not execute, block, sign or authorize payments, authenticate provider evidence, or establish production coverage. The Lab is a CLI and Python diagnostic package. The separate payment API and SDKs are local evaluation interfaces; production payment control is not offered here.
Labs · AI execution preview
One job. One budget.
Keep the approved budget attached to the same AI job across retries, agents and provider changes. Inspect the SDKs and the recovery contract. Request a local evaluation for one workflow.
Python + JavaScript/TypeScript SDKs · Local evaluation · RC15.3 candidate