Heimdall technical due diligence

Composable execution for an agent-native bank.

This pack explains the production-shaped contracts behind the public prototype. External providers remain replaceable ports; material actions remain governed and evidenced.

System topology

Competition at service and asset. Replaceability at access and platform.

ExperienceFamily Wealth, mobile, back office, partner channels

↓ intent / ↑ evidence

Agentic GatewayIntent → deterministic plan → approval gate → DSL commands

↓ governed command

DBBs + DSL EngineGather → execute → acknowledge, with evidence at each phase

Event SpineImmutable domain events and projection inputs

Projected LedgerBalanced postings and multi-form deposit truth

↓ injected ports

IdentityGovID, document/biometric, bank-data route

Money railsFPS / ISO 20022, custody and token networks

ControlsCompliance, policy, decisions, evidence export

Canonical contracts

The bank is a graph of parties, authority, products and events.

Party and authority

PartyRelationshipEntitlement

Identity and authority are separate. Family membership, corporate role and delegated authority never imply unrestricted access.

Family wealth

FamilyCircleSharedGoalFamilyGoalPermission

Shared purpose is represented without collapsing individual ownership, consent or beneficial interest.

Money and ledger

MoneyPostingWallet

Every movement resolves to balanced postings. Tokenised deposits retain visible 1:1 bank backing.

Execution and evidence

CommandDomainEventEvidenceStep

Commands are idempotent. Events carry causation. Evidence records what was gathered, executed and acknowledged.

Execution flow

One path from intent to auditable outcome.

1
Capture intent
A customer, colleague or trusted agent expresses an outcome rather than selecting an internal banking operation.
2
Prepare a constrained plan
The gateway maps supported intent to canonical commands. Unsupported or ambiguous intent stops before execution.
3
Gather evidence
The selected DBB resolves identity, authority, policy, balances and provider context through injected ports.
4
Apply the approval policy
Material actions remain blocked until an authorised human records approval.
5
Execute and project
The engine posts balanced ledger entries, publishes events and updates operational projections.
6
Acknowledge with evidence
The result contains phase-level evidence, causation and provider references suitable for operational and audit views.

Controls and failure boundaries

Agent-native does not mean agent-uncontrolled.

Boundary	Control	Evidence
Identity	Provider route is explicit; failed verification becomes needs-action or referral.	Method, provider result, screening state.
Authority	Access is granted by scoped entitlement, never inferred from relationship.	Grant event, scope, restrictions and principal.
Material action	Proposal cannot execute before human approval.	Proposal ID, approver and execution causation.
Money movement	Ledger rejects unbalanced posting sets.	Posting set, command ID and resulting event.
Token issuance	Bank backing and issued token totals remain equal.	Backing balance and custody transaction reference.
Replay	Stable idempotency keys prevent repeated application.	Idempotent-skip evidence.

Deployment path

Adapters change. Core contracts remain.

Public proof

Browser + deterministic adapters

The same engine and DBBs run entirely client-side for a repeatable demonstration with no keys or live money.

Design-partner pilot

Controlled services + sandbox rails

Replace in-memory projections with durable stores and outbox patterns; connect approved provider sandboxes behind existing ports.

Regulated deployment

Partner licence + production controls

Operate inside the bank's governance, security, data residency, model risk, provider and regulatory obligations.

Prototype boundary

This material demonstrates architectural feasibility. It is not a licensed bank, production security design, regulatory approval or offer of regulated services.