Deploying it: one process, two kits, shadow first

BEAP v0.1 · Draft / Design Partner ReviewDated 2026-09-11. A draft the banks reviewing it can still change. Not a finished standard, and it may change before v1.0.

The component in front of the core system ships as one process a bank runs inside its own boundary. A workflow proposes a banking action to it and receives a verdict; in enforce mode an allow is claimed and executed in the same call and the outcome of that one attempt comes back with its effect evidence. The proposer never receives a grant, and the credential the process presents to the core is never reachable from a request.

Where it sits

YOUR CHANNELS
Agent · App · Employee · Batch
            |
            v
       PROPOSE ACTION
            |
            v
+-----------------------------+
| DECIONIS EXECUTION AUTHORITY|
|                             |
| Rules -> Authority -> Evidence
+-----------------------------+
            |
     +------+-------+
     v      v       v
   ALLOW ESCALATE BLOCK
     |      |
     |   Approvers
     |      |
     +---+--+
         v
   EXECUTION BOUNDARY
         |
         v
YOUR BANKING SYSTEMS
Core · Payment Hub · Lending · Ledger

Between your workflow and your core, holding the credential on its own side

The pattern a search engine may describe to you, in which the proposing agent carries an execution token to an API gateway that validates it, hands the grant to the proposing side. The profile forbids that, and these kits do not do it: the executor is where the gateway would be, and the proposer carries nothing.

The two kits

Kit	For	What it deploys
Temenos	A bank whose lending runs on Temenos Transact and whose payments go through a Temenos payments hub.	One executor per adapter: temenos-transact for arrangement activities such as creating a loan, temenos-tph for payment orders and batch releases. The adapters are patterns built from what the Temenos developer portal showed publicly on a recorded day; every endpoint, host, header name and credential is yours, and nothing has been run against a Temenos environment. Temenos marks belong to Temenos Headquarters SA; there is no affiliation and no endorsement.
A lending rail	A lender on a platform whose credit decision, disbursement engine and ledger are separate services.	One executor with the rails-lending adapter. The credit decision is recorded as the lender's decision once a credit officer's sign-off is bound to the exact terms; a release is refused outright when the decision is not current, when the instruction differs from what was decided, when capacity is not confirmed, or when a product structure's preconditions are not evidenced, and otherwise asks for a maker and a distinct checker. It is confirmed only from the ledger's posting read back. No rail is named and none has been run against.

Each kit carries the manifests (one replica, read-only root filesystem, non-root, a network policy that lets only the proposing workflow in and only the authority and the core out, Secret references and never a Secret), an adapter configuration to fill in, and a runbook from shadow to controlled enforcement to enforcement. The lending-rail kit adds a starter policy bundle and static signals for a rehearsal.

Three modes, taken in order

Shadow. BEAP_MODE=shadow, which is how the manifests ship. Every proposal is evaluated and recorded and nothing is executed. Compare what the rules would have said with what the workflow did; the platform describes the same posture for its other surfaces at shadow mode.
Controlled enforcement. BEAP_MODE=enforce for one action, one workflow, one team. The sign-offs the workflow collects are presented with the proposal, re-verified under registered keys, and refused with the reason when they do not bind this exact instruction.
Enforcement. The action is reachable only through the executor.

What it answers

The contract is served by the process at /.well-known/openapi.json and pinned by test to the routes it registers. The rows below are held to the same list.

Route	Credential	What it does
`GET /health`	None	Liveness.
`GET /ready`	None	Readiness: the configuration loaded, the adapter constructed, and the mode.
`GET /.well-known/openapi.json`	None	This contract.
`POST /v1/actions`	Caller token	Propose one banking action, with its sign-offs where it has them. The answer is a verdict; in enforce mode an allow is claimed and executed in the same call.
`POST /v1/actions/{request_id}/reconcile`	Caller token	Ask what became of an attempt whose outcome is unknown. Read-only: it never sends the action again.

What it is configured with

Every value comes from the environment; files are mounted and read once on the trusted side. A missing key is a refusal to start that names the key and never its value. The reference authority and the synthetic adapter refuse to run where NODE_ENV is production, by configuration and on their own account.

Key	Required	Purpose
`BEAP_MODE`	Optional	shadow (evaluate and record, never execute) or enforce. Absent means shadow.
`BEAP_AUTHORITY`	Always	decionis, the hosted execution authority, or reference, refused in production.
`BEAP_TENANT_ID`	Always	The organization the actions belong to.
`BEAP_ADAPTER`	Always	temenos-transact, temenos-tph, rails-lending, or synthetic, refused in production.
`BEAP_ADAPTER_CONFIG_FILE`	With any adapter but the synthetic one	The adapter's mapping and transport configuration, JSON; every URL and header name is yours.
`BEAP_DOWNSTREAM_CREDENTIAL_FILE`	Optional	The credential the adapter presents to your core, mounted as a file; the proposer never sees it.
`BEAP_CALLER_TOKEN_FILE`	Always	The credential your workflow presents to this process, mounted as a file.
`DECIONIS_API_URL`	With the hosted authority	The hosted authority, over HTTPS.
`DECIONIS_API_KEY_FILE`	With the hosted authority	Your organization's API key, mounted as a file and read once.
`BEAP_POLICY_BUNDLE_FILE`	With the reference authority	The policy bundle, or an array of them, the reference authority evaluates.
`BEAP_SIGNALS_FILE`	With the reference authority	Where the reference authority reads policy inputs: a static file, or the URL of your signal endpoint.
`BEAP_APPROVER_KEYS_FILE`	Optional	Approver public keys the reference authority verifies sign-offs against; without it no sign-off verifies.
`BEAP_ATTEMPT_TTL_SECONDS`	Optional	How long an attempt stays reconcilable in this process. Absent means one day.
`PORT`	Always	The port this process listens on.

What is still open

With the hosted authority, the process sends the bound action and its digests and receives a verdict; escalation resolves through Presence, and a set of sign-offs presented with the proposal reaches the authority as a digest bound into the intent. Bank-side policy signals and locally verified sign-off sets are evaluated by the reference authority, which is the rehearsal and the design-partner evaluation, not a deployment.
A confirmed effect is this profile's statement from its own record until the hosted platform accepts an observer for it. What the platform runs today for financial infrastructure is stated on its own page.
Reconciliation is per process: an attempt whose answer never came is reconciled from the executor that made it, which is why the manifests run one replica.
Nothing here has been run against a Temenos environment or any lending rail. The rehearsal runs both adapters against loopback stand-ins shaped like the published samples.

How to get it

The executor, the kits and the rehearsal are in the repository, which is not yet public and is shared with design partners on request; no package is on a registry, and no install line is given until one resolves. Get started says which step to take first; the review guide says how to bring one workflow. Links checked 2026-09-13.