Board Assurance Summary - Autonomous AP Payment Run APRUN-2026-06-09-A

Organisation: Caldera Robotics Ltd · Period: 2026-06-09 09:00–09:11 UTC (settlement reconciled T+0 EOD) · Assurance basis: SE v0.1-draft evidence, scoped - see Reliance Boundary.

The assurance statement

An authorised autonomous process executed 14 payment instructions under delegated authority AD-7844. [env:0007 | authority.authority_context_id] [env:0075 | summary.committed_count] - all 14 commit events carry authority_context_id = AD-7844 with delegation receipt delrec:AD-7844/2026-04-02 granted by the CFO [env:0007 | authority.delegation_receipt_id] [env:0007 | authority.delegator_id] under payment policy v3.2 in force throughout [env:0007 | authority.policy_version].

All payments remained within approved policy boundaries. Each of the 14 instructions passed three pre-commit policy checks - approved-beneficiary, per-payment limit, and duplicate-key - evaluated before execution, 42 control evaluations in total, all passed [env:0004 | controls.control_evaluation_phase] [env:0004 | controls.checks[*].control_result]. Peak single-payment authority utilisation was 95.6% of the €25,000 limit (payment 3) [env:0013 | controls.checks[1].observed.authority_utilisation_ratio]; batch aggregate €117,406.18 used 78.3% of the €150,000 batch limit [env:0075 | summary.batch_limit_utilisation_ratio].

No exceptions requiring human intervention occurred. Exception count 0, human-intervention count 0 [env:0075 | summary.exception_count] [env:0075 | summary.human_intervention_count]; no approval was required under the policy rule for at-limit payments to approved beneficiaries [env:0004 | authority.approval_status] [env:0004 | authority.approval_basis].

Evidence integrity validated. All 76 envelopes form an unbroken SHA-256 hash chain (re-verified at report generation), externally anchored at 5-minute intervals - 3 anchor receipts [env:0037 | anchoring.anchor_receipt_id]; emission ran fail-closed for commit-boundary actions throughout [env:0007 | emission.emission_fail_posture]; liveness heartbeats present for every 60-second interval of the run with zero silent windows [env:0009 | liveness.liveness_status].

No cross-tenant data exposure detected. Tenant-boundary and cross-customer exposure indicators are false, on the stated basis that runtime egress was limited to the bank API and ERP [env:0074 | boundary_assessment.cross_tenant_exposure_indicator] [env:0074 | boundary_assessment.basis].

What the board should know

External confirmation, not self-assertion: every payment carries a three-rung acknowledgment ladder - transport (HTTPS 200), protocol (bank API ACCEPTED), business (ISO 20022 pacs.002 status ACSC = settlement completed) [env:0007 | acknowledgments[*]] - and the bank’s end-of-day camt.053 statement reconciles 14 of 14 instructions [env:0073 | reconciliation.statement_count_bank].
Completeness is measured, not asserted: the in-scope population is independently defined (ERP approved-invoice queue: 14 due; bank statement: 14 booked) and evidence coverage is 14/14 = 100%, tamper-evident coverage 100% [env:0073 | reconciliation.evidence_population_ref] [env:0073 | reconciliation.evidence_coverage_ratio].
Leading indicator: one payment ran at 95.6% of its limit; nothing breached, but limit headroom on supplier SUP-003 invoices is worth a policy review.
Recommended position: continue autonomous operation at current scope; no restriction indicated by this run’s evidence.

Reliance boundary

This report evidences this run only; it supports internal assurance and audit reliance for the stated period and population. It is not a compliance certification, and statements are bounded by the capture boundary declared in the Regulator Pack (§4). Signatures and anchor receipts in this golden trace are stubs pending the SE v0.1 signing profile.

Audit & Control View - APRUN-2026-06-09-A

1. Controls relevant and evidenced

Three preventive controls (control set ctl:ap-pay/v3.2) were evaluated pre-commit for each instruction [env:0004 | controls.control_evaluation_phase]:

#	Beneficiary	Amount	CTL-BENEF-01 approved-list	CTL-LIMIT-02 per-payment limit	CTL-DUPL-03 duplicate key	Human approval
01	SUP-001	€4,475.00	passed	passed (17.9%)	passed	not_required
02	SUP-002	€12,880.50	passed	passed (51.5%)	passed	not_required
03	SUP-003	€23,900.00	passed	passed (95.6%)	passed	not_required
04	SUP-004	€9,240.10	passed	passed (37.0%)	passed	not_required
05	SUP-005	€3,318.75	passed	passed (13.3%)	passed	not_required
06	SUP-006	€15,602.00	passed	passed (62.4%)	passed	not_required
07	SUP-007	€7,777.77	passed	passed (31.1%)	passed	not_required
08	SUP-008	€1,949.99	passed	passed (7.8%)	passed	not_required
09	SUP-009	€11,025.40	passed	passed (44.1%)	passed	not_required
10	SUP-010	€6,890.00	passed	passed (27.6%)	passed	not_required
11	SUP-011	€2,475.25	passed	passed (9.9%)	passed	not_required
12	SUP-012	€8,112.60	passed	passed (32.5%)	passed	not_required
13	SUP-013	€5,230.95	passed	passed (20.9%)	passed	not_required
14	SUP-014	€4,527.87	passed	passed (18.1%)	passed	not_required

Result: 42/42 control evaluations passed; 0 failed; 0 bypassed; 0 not_observed. Approval was not_required under policy v3.2’s rule for at-or-below-limit payments to approved beneficiaries [env:0004 | authority.approval_basis]; consequently no SoD/dual-control assertion is made or needed for this run - the control relied upon is the delegated-limit + approved-list pair, both evidenced above.

2. Population and completeness (IPE basis)

Population definition: ERP approved-invoice queue at 08:55Z (14 due) reconciled against bank statement FMB-STMT-2026-06-09 (14 booked) - independently reconciled, not self-reported [env:0073 | reconciliation.population_basis].
Coverage: envelopes 14/14 (100%); tamper-evident 100% [env:0073 | reconciliation.evidence_coverage_ratio].
Sequence continuity: envelope sequence numbers 0001–0076 contiguous, no gaps (stream-internal proof); heartbeats at 60s intervals, zero silent windows (silence semantics) [env:0009 | liveness.declared_heartbeat_interval_s].

3. Evidence quality

Origin/basis: runtime-observed; commit confirmations are third-party confirmed (pacs.002 ACSC per payment) and source-system corroborated (camt.053) [env:0007 | evidence_quality.corroboration_state] [env:0073 | evidence_quality.corroboration_state].
Corroboration coverage decomposition: anchored 100% · receipted 14/14 · provider-only 0.
Point-in-time validity: policy v3.2 effective from 2026-05-01, in force at every event [env:0007 | authority.policy_version]; delegation valid 2026-04-02 → 2026-12-31.
Model context: sampling parameters recorded (temperature 0.2, top_p 0.9); replay claim scoped - reproducible in distribution, not in instance [env:0002 | model.sampling_parameters]; reasoning artifacts provider_withheld - disclosed, not silent [env:0002 | model.reasoning_artifact_availability].

4. Findings register

No exceptions, deficiencies, or open actions arise from this run. One observation (OBS-001, advisory): peak per-payment utilisation 95.6% - recommend limit-headroom review for SUP-003. Owner: AP process owner. Due: next policy cycle.

This report is produced to AXES, an open, public working-draft standard for automation execution evidence, stewarded by Magentix AI. The standard is developed in the open and invites review.

See the standard's origin on GitHub

Other views of the same evidence

The Golden Trace example is published in several role-specific views. Each option below opens the same underlying record, framed for a stated profession. Select a view to read it, or share a link with a colleague whose role differs from yours.

Open the audit and control view →
payment operations, fraud, and financial-crime roles
Open the forensic pack →
dispute and investigation teams
Open the machine-readable subset →
scheme, PSP, and facilitator operators
Open the regulator pack →
policy, compliance, and consumer-protection roles
Open the audit and control view →
accountants, bookkeepers, and reconciliation leads
Open the audit and control view →
accountancy and audit professional bodies
Open the conformance view →
insurance underwriting and claims
Open the regulator pack →
consumer-platform and consumer-protection roles

Each view ends with the same review questions. The public requirements register is strengthened when multiple professions contribute.

Review this example

You have read the example report above. The questions below ask what would need to change before you could rely on a report like this in your role. Your answers are added to the public AXES requirements register.

Common questions (every reviewer) C1. Which view did you read? * C2. What in this report would not survive contact with your world? * The thing that would break, be queried, or be quietly distrusted the moment a colleague in your role saw it. C3. What single field or gap is missing that you would need before you could rely on this? * One thing - the one that matters most in your role. C4. Today, without a record like this, how do you answer the question your role actually faces?

Questions for your role

Your autonomous workflows commit funds; month-end discovery is too late.

What visibility of delegation scope and drift would you need at execution time? * What would you want to happen the moment a workflow acts outside scope, and what evidence in hand? * Who would consume this internally?

Attribution and contact

E1. May we credit you as a design partner on the standard? * Design partners are acknowledged in the standard's contributor record. This is standards review, not a testimonial. Credit by name and role Role only Anonymous

E2. Name E3. Role and organisation type Organisation type is enough ("a UK clearing bank", "a mid-tier audit firm"); a specific employer name is not needed. E4. Email, if you are open to one clarifying question from the steward Used only to ask about your submission; not a mailing list. Not published in the public register. E5. Would you review a later draft?