Transactional overview

Sill Transactional is the four-step pipeline that turns an agent’s authorization request into a settled charge with cryptographic proof: a signed mandate carries the agent’s identity and intent; the policy engine evaluates that mandate against the site’s active rule set; approved mandates authorize a charge against the merchant’s existing processor (Stripe today); every step is written to the signed, Merkle-chained audit envelope. Sill never custodies funds — the merchant’s processor holds the card, authorizes, settles, and pays out. Sill issues the signed authorization and the audit record.

Transactional adds three layers on top of Discovery. Discovery already identifies and logs agent traffic; Transactional is what makes an agent interaction enforceable — a signed intent, a deterministic rule outcome, and a cryptographic record of who approved what, when, and against which policy version.

The pipeline

Every Transactional interaction moves through the same four stages, in order:

Signed mandate. The agent submits an authorization request as a signed envelope. The mandate carries the agent’s identity (resolved against the seeded identity registry), the principal it acts for, the skill it intends to invoke, and the parameters. Mandate IDs are prefixed ULIDs (mnd_…). See Signed mandates.
Policy evaluation. The site’s active policy — a versioned, ordered set of rules, one active per site — runs against the mandate. Each rule has a category, a DSL expression, and an on_fail of reject or escalate. The engine emits one of three outcomes: approve, escalate, or reject.
Side effect. An approve proceeds to payment authorization (today: Stripe, against a merchant-saved opaque payment-method token). An escalate pauses the mandate and routes it to a human reviewer in the dashboard; the reviewer’s resolution is recorded before any downstream call. A reject ends the pipeline with no side effect.
Signed audit record. The mandate, the policy outcome, any HITL resolution, and the processor response are written to the audit envelope — ed25519-signed and Merkle-chained — and become independently verifiable against the public JWKS.

sequenceDiagram
    autonumber
    participant Agent as Agent
    participant Edge as Sill edge (mandate + policy)
    participant Reviewer as Human reviewer
    participant Stripe as Stripe
    participant Audit as Sill origin (audit envelope)

    Agent->>Edge: Signed mandate (mnd_...)
    Edge->>Edge: Verify signature + identity
    Edge->>Edge: Evaluate active policy
    alt outcome = reject
        Edge-->>Agent: rejected (no side effect)
    else outcome = escalate
        Edge->>Reviewer: Pause + route to dashboard
        Reviewer-->>Edge: approve or reject
        opt reviewer approved
            Edge->>Stripe: Authorize charge (merchant-saved token)
            Stripe-->>Edge: charge result
        end
    else outcome = approve
        Edge->>Stripe: Authorize charge (merchant-saved token)
        Stripe-->>Edge: charge result
    end
    Edge->>Audit: Signed, Merkle-chained record
    Audit-->>Agent: Verifiable outcome (mandate_id, audit_id)

The mandate engine runs at Sill’s edge; the audit envelope, registry, and connectors run at the origin. The split is deliberate: hot-path evaluation is co-located with the verification surfaces, and the audit and signing material stays on the origin.

What each layer does

Layer	Where it runs	Purpose
Mandate verifier	Sill edge	Validates the signed envelope, resolves the agent identity, normalizes the canonical mandate.
Policy engine	Sill edge	Runs the active versioned rule set; emits `approve`, `escalate`, or `reject`.
HITL queue	Sill origin + dashboard	Pauses escalated mandates; routes to a human reviewer; records the resolution.
Payment authorization	Sill origin → Stripe	Calls Stripe to authorize a charge against the merchant-saved opaque token.
Connector layer	Sill origin	Wires skill outcomes back to the merchant’s commerce stack (Stripe today; Shopify in test mode).
Audit envelope	Sill origin	Appends a signed, Merkle-chained record for every step. Independently verifiable.
Public JWKS	Sill edge	Publishes the ed25519 signing key for third-party signature verification.

What Sill is not

Sill is not a payments processor, money transmitter, fraud system, blockchain, identity-verification service, loyalty platform, or PCI-certified entity. The cardinal architectural invariant: Sill never holds the card and never holds the money. Sill handles only opaque processor tokens (Stripe pm_* / tok_* / SPT references); raw card numbers never enter any Sill system. The merchant’s processor authorizes, captures, settles, and pays out. Sill issues the signed authorization and the audit record.

Today versus roadmap

What is live on the Transactional pipeline today:

Stripe live rail — operational in limited production. The signed mandate → policy → Stripe authorize → signed audit path has cleared and refunded real live-mode charges on a single Sill-controlled merchant. See Payments for the bounded claim and Refunds for the refund path (charge.refunded and charge.dispute.created webhook handlers).
Policy engine — versioned, ordered rules with approve / escalate / reject outcomes; mappings to OWASP LLM Top 10, OWASP Top 10 for Agentic Applications, MITRE ATLAS, and NIST AI RMF. See Policy engine and Compliance.
Human-in-the-loop escalation — paused mandates surface in the dashboard for reviewer resolution before any side effect. See Human in the loop.
Signed, Merkle-chained audit envelope — every mandate, every outcome, every reviewer action; ed25519 with HTML bundle export. See Audit envelope and Verify a signature.

On the roadmap, not live:

Shopify live-rail settlement — a separate gate from Stripe live; today the Shopify connector is test-mode only.
The Agentic Commerce Protocol (ACP) (Shared Payment Tokens via Stripe) — built but dormant behind a feature flag; not enabled for production use.
The Universal Commerce Protocol (UCP) (catalog payments) — designed; pending a signed-fixture validation.
x402 (on-chain HTTP-native payments) — deferred.

Frequently asked

Does Sill ever hold the money or the card?

No. Stripe holds the card, authorizes the charge, settles to the merchant’s connected account, and pays out. Sill issues the signed authorization and the audit record. No funds enter a Sill-controlled account at any step. Sill handles only opaque processor tokens.

Where do mandates get signed and verified?

The mandate envelope itself is signed by the agent (or its principal); Sill verifies that signature against the agent’s registered ed25519 public key in the identity registry. Sill’s own signature is added to the audit record. Both use ed25519 (RFC 8032) with base64url encoding, and Sill’s signed surfaces use detached JWS (RFC 7515 / EdDSA per RFC 8037) over RFC 8785 JCS-canonical payloads. See Verify a signature.

What happens when a rule escalates instead of rejecting outright?

The mandate is paused — no payment call, no connector call. It appears in the dashboard’s reviewer queue. A reviewer with the reviewer, admin, or owner role resolves it as approve or reject; the resolution is appended to the audit envelope before the pipeline proceeds. See Human in the loop.

How are refunds handled?

Refunds run back through the same signed-mandate path. Sill’s webhook handlers cover the Stripe charge.refunded and charge.dispute.created events and write the refund or dispute outcome to the audit envelope alongside the original mandate. See Refunds.

Can I enable Transactional today?

Transactional is currently in early access, validated in limited production on the live Stripe rail. If you need access for evaluation, contact the founder through the email on sill.so. Discovery is free and unlimited today and can be installed without any Transactional access.