Tested templates · adapt to your shop
Start from a tested template, not a blank schema editor
You model your own work on AGLedger with custom contract types. A recipe means you do not start that from nothing.
A recipe is a tested, multi-step set of contract types for a whole domain workflow - the types, their relationships, and the Notify config. Import one into your own Server, adapt it to your gates and systems of record, and you have a working pipeline instead of a blank page. For how recipes fit the product, see how it works.
Why recipes matter
AGLedger does not need to understand your whole business. It needs the contract shape for the work an agent is allowed to perform - the records, the gates, the authority checks, and the notifications that show up in any controlled workflow.
A recipe gives you that shape. You import the structure, then replace the example fields, thresholds, and systems of record with your own. The structure is given; the policy stays yours.
You are never starting from blank
Every instance seeds example contracts
A new org is created with editable example contracts already in place - a generic notarize-only on-ramp plus a gate example. The floor against the blank page.
Industry recipes for a whole workflow
For a head start on an entire domain, an industry recipe gives you a tested, multi-step pipeline to adapt rather than author.
Available recipes
Insurance - auto claims
watch demo →files →First notice of loss through coverage, property and bodily-injury assessment, fraud and SIU review, an engine-decided authority gate, and the human settlement decision.
- Records
- intake (FNOL), coverage check, damage and injury assessment, fraud / SIU referral, settlement outcome
- Gates
- authority band (engine), settlement decision (human)
- Notify
- claims ops, SIU / fraud
- System of record
- the carrier’s claims system
- Human role
- supervisor only on the over-authority settlement
Exercised cold across multiple agent models, at scale, on live infrastructure.
Healthcare - prior authorization
watch demo →files →A prior-auth decision rendered by the payer utilization-management system, with contested cases routed to a medical director - a human in the loop only where one is needed.
- Records
- PA request, payer adjudication disposition, appeal / peer-to-peer re-determination
- Gates
- medical-director determination (human), appeal re-determination (human)
- Notify
- PA determinations, UM queue
- System of record
- payer utilization-management system (HL7 Da Vinci PAS / X12 278)
- Human role
- medical director only on contested cases
Built against a reference HL7 Da Vinci payer system.
Finance - KYC and sanctions
watch demo →files →Sanctions and PEP screening, an engine-decided score-band gate, two-tier review, and the regulator-facing no-tip-off notice.
- Records
- onboarding case, sanctions screen, regulatory report (SAR / OFAC)
- Gates
- score band (engine), alert disposition (human), onboarding decision (human)
- Notify
- compliance ops, regulator reports, applicant notices
- System of record
- external sanctions / PEP screening engine (OpenSanctions)
- Human role
- L1 analyst dispositions the alert; L2 / MLRO renders the onboarding verdict
Built against OpenSanctions screening.
Payments - disputes and chargebacks
watch demo →files →The card-dispute lifecycle: the filing, a human-authorized one-shot decision to contest or concede with the evidence package hash-bound before it is submitted, and the relayed won/lost disposition. Includes the Visa Compelling Evidence 3.0 and inquiry paths.
- Records
- dispute filing, final disposition (won / lost + funds movement)
- Gates
- contest / concede decision (human), CE3.0 evidence decision (human), inquiry resolution (human)
- Notify
- disputes ops, fraud review
- System of record
- Stripe dispute API (issuer and network render the verdict)
- Human role
- a fraud-ops lead authorizes the contest or concede; a separate analyst assembles the evidence
Built against Stripe’s dispute API as the system of record.
Content moderation - DSA takedown
watch demo →files →The EU Digital Services Act enforcement lifecycle: an inbound flag, the platform’s own human-gated takedown decision, the Article 17 statement of reasons to the user, the Article 24(5) submission to the DSA Transparency Database with its receipt bound on-chain, and the Article 20 appeal.
- Records
- inbound flag, Article 17 statement of reasons, Article 24(5) Transparency DB submission + receipt
- Gates
- enforcement decision (human, own-decision), Article 20 appeal (human)
- Notify
- moderation ops, transparency & appeals
- System of record
- none upstream - the platform’s own call; downstream, the EU DSA Transparency Database returns a receipt
- Human role
- moderator submits; an independent reviewer renders each verdict
Built against a self-hosted EU DSA Transparency Database.
Software delivery - GitHub
watch demo →files →An agent-driven code-delivery flow end to end: the authoring agent’s stated intent and claims, the CI conclusion as GitHub computed it on the exact commit, the human authorization to merge or deploy rendered before the sha-pinned one-shot, and the outcome as GitHub reports it. GitHub is the first system of record in the catalogue that holds human gates of its own; the recipe composes AGLedger’s Gate with them under a one-decision-one-holder rule.
- Records
- authored change (intent, diff hash, claims), CI conclusion, review-verdict relay, deployment-approval relay, delivery outcome
- Gates
- merge authorization (human), deploy authorization (human) - or relay GitHub’s native review and environment gates instead; one holder per decision
- Notify
- delivery ops, release authorizations
- System of record
- GitHub (Actions CI, protected branches, environment protection)
- Human role
- a release manager renders the merge or deploy verdict; GitHub’s author-cannot-self-approve stays on as an independent second line
Built against live GitHub: Actions, protected branches, and environment protection.
Tax - HMRC MTD VAT filing
watch demo →files →A UK VAT return filed to HMRC under Making Tax Digital: the open obligation as HMRC states it, the nine-box return, an engine pre-flight arithmetic gate, the responsible officer’s statutory “true and complete” declaration held before the irreversible submission, and HMRC’s returned form bundle number (or typed rejection) bound to the exact bytes filed. The first government system of record in the catalogue, and the first where the bound receipt is itself the legally operative artifact: the taxpayer’s proof of having filed, and of when.
- Records
- obligation retrieved, return prepared, filing receipt (form bundle number or typed rejection), penalty observation
- Gates
- pre-flight well-formedness (engine), statutory declaration (human)
- Notify
- VAT filing ops, the officer’s declaration queue, receipts and penalties
- System of record
- HMRC Making Tax Digital VAT API (HMRC alone adjudicates acceptance)
- Human role
- the preparer submits the return; a distinct responsible officer renders the declaration verdict
Driven live against the HMRC developer sandbox, including the typed-rejection and duplicate-submission paths.
Employment - FCRA adverse action
watch demo →files →A background screen where the gate is a clock. The CRA renders the adjudication; an engine gate auto-clears only a clean pass and routes everything else to a human EEOC individualized assessment. If the outcome is adverse, the FCRA two-step runs: the pre-adverse notice starts a mandatory waiting period so the candidate can dispute, an engine-enforced wait gate refuses a final action before the window elapses (the clock runs on the engine’s own signed timestamps, so nothing the orchestrator supplies can shorten it), and the final §615(a) decision is a person’s call. The elapsed interval is a litigated fact (Tyus v. USPS); here it is provable offline from two signed timestamps.
- Records
- screening order, CRA adjudication (verbatim label + normalized outcome, report hash), pre-adverse notice (starts the clock)
- Gates
- adjudication auto-clear (engine), wait window (engine-enforced clock), individualized assessment (human), final adverse action (human)
- Notify
- screening ops; candidate notices, scoped server-side to the two notice types
- System of record
- external consumer reporting agency (Accurate Background)
- Human role
- a reviewer renders the EEOC assessment; a distinct authorizer renders the final adverse action
Driven live against the Accurate Background sandbox; in a blind run, a cold agent reported a final action inside the window as lawfully impossible rather than working around the clock.
We add and exercise new verticals over time. If you need one that is not here yet, tell us and we will build it with you.
Adapt it to your shop
A recipe is a starting point you own, not a turnkey product. Import it under your org as ordinary, editable contracts, then reshape it: edit the types to your fields, wire your own system of record or screening engine into the gate seam, and set your own thresholds and authority bands. The recipe gives you the structure and a working example; the decisions and the policy stay yours.
The recipe is plain files. Follow the install guide to register a recipe against your own Server in one command. If you want help adapting one to your process, talk to us.