IRAH / REUSABLE FOUNDATION

Connect your systems.
Make each action accountable.

Connectors, document processing, AI agents, permissions and monitoring form a shared engineering foundation. Each engagement adds its own data, rules and approval workflow.

Watch this workflow ↓Scope a pilot →

Reference architecture and simulated workflow. Capabilities and deployment readiness are validated for each engagement.

REUSE THE FOUNDATION / CONFIGURE THE WORK

Five building blocks. Different business workflows.

ConnectorsBring approved APIs, files and legacy records into a consistent format.

Document processingExtract fields, retain source references and flag uncertain results.

AI agentsRetrieve approved knowledge, prepare actions and call allowed tools.

PermissionsSeparate organisations and roles; require approval where decisions matter.

MonitoringTrack errors, cost, latency and the outcome of each action.

For an insurer, this can support claims review. For a ministry, it can connect citizen demand, existing provision and delivery gaps. The records and access rules remain specific to each customer.

ARCHITECTURE / FOLLOW THE DATA

From authorised input to a verified action.

Request → permission check → source retrieval → AI-assisted work → human approval → system update and audit.

Technical detail: boundaries, approvals and data movement

Customer boundaryAuthenticate users, apply department and record permissions, and minimise the data retrieved.

Model boundaryOnly approved content goes to the selected model. Redaction, retention and external endpoints are agreed before integration.

Action boundaryValidate outputs against business rules. Require an authorised approval before a consequential write; retain the reviewer and source references.

Operations boundaryLog actions with access controls; monitor failures, retries and cost. Define retention, backups, recovery and incident ownership.

INTEGRATION READINESS REGISTER

See what needs to be checked before integration.

Choose the interface type to review its current public evidence and the checks needed during discovery.

Public evidence reviewed: No named connector has a published test record here. Treat all interfaces as unverified until the customer system, version, permissions and test result are recorded.

Show

System or interface	Readiness today	Evidence needed to advance
Customer and ministry APIs REST / JSON · API gateway	Needs assessment No named system, version or successful test is published.	Review API documentation, sandbox credentials, scopes, rate limits and read/write behaviour.
Legacy databases and registries SQL / customer-managed records	Needs assessment The architecture supports connecting systems of record; no specific database connector is evidenced.	Confirm database, schema, network route, least-privilege access and reconciliation rules.
Documents and spreadsheets PDF · scanned files · CSV · XLSX	Adapter unverified Document intelligence is described; supported formats and extraction test results are not published.	Test representative files, languages, scan quality, field accuracy and source citations.
Identity and single sign-on Customer identity provider · SSO	Needs assessment Role and permission controls are described; no named identity-provider test is published.	Validate protocol, role mapping, user lifecycle, audit events and security review.
Events and notifications Webhooks · queues · event bus	Needs assessment Event based integration is part of the architecture; no named provider test is published.	Confirm event contract, delivery guarantees, retries, idempotency and monitoring.
Commercial or open models Hosted endpoint · private model service	Needs assessment Model choice is an engagement decision; no production endpoint or benchmark is published.	Agree model, data boundary, licence and evaluation set; test quality, latency and cost.

Tested connector means a named system and version passed an agreed test. Reusable adapter means a versioned adapter is documented and has test evidence. Requires development means a gap is confirmed after access and technical discovery.

This is a public evidence register, not a claim that no internal work exists. IRAH should update each row when it can publish a system name, version, test date and permitted evidence.

MODEL CHOICE

Choose by the task and constraints.

Commercial APIs and open models are candidates, not a fixed commitment. Selection follows an evaluation on your workflow.

Your main priority

Cost first

Use rules or smaller models for simple tasks and reserve larger models for exceptions. Measure the whole workflow cost, including review.

Evidence: cost per accepted task, latency and escalation rate.

DEPLOYMENT & RESPONSIBILITY

Agree where it runs—and who keeps it running.

These are deployment approaches to assess. Support, recovery targets and infrastructure requirements are confirmed in the project scope.

Private environment

Use a dedicated network and restricted endpoints, with identity and logging integrated into customer controls.

Customer: network and security approvals. IRAH: application integration and agreed operational support. Model hosting is decided separately.

THREE SHORT WORKFLOW DEMOS / SAMPLE DATA

See the decision each workflow helps prepare.

Choose a use case, then step through its input, checks, human review and conclusion. All records and figures below are illustrative; the demos do not connect to live systems or make decisions.

UTILITY ASSET REVIEW

Turn field observations into a checked maintenance worklist

Sample input: Synthetic inspection notes + asset register + maintenance history

STEP 4 OF 4

Decision ready

The operations manager receives one traceable worklist and approves, revises or defers each action.

Conclusion: 2 assets for priority review · no work order is dispatched automatically

Scope this workflow →

Leave discovery with a concrete pilot scope.

One workflow, agreed data sources, connector readiness, hosting responsibilities, acceptance measures and an estimate of delivery effort.

Scope a pilot →Review the evidence approach →

ARCHITECTURE PRINCIPLE

Choose each capability for a reason.

Use an ordinary database for authoritative operations. Add caching when workload evidence supports it, AI when a decision can be evaluated, and blockchain only when multi-party tamper evidence is justified.

DESIGN TRADE-OFFS

The right technology changes by workload.

Transaction systems

Reliable writes, business rules, reconciliation and access controls.

Intelligence services

Model evaluation, grounded evidence, confidence and human decisions.

Trust and resilience

Recovery, observability, source integrity and auditable workflows.