Operative Solutions

Questions for an AI Strategy

Most AI strategies fail before they start because the right questions were not asked at the outset. The questions below are the ones that determine whether a strategy produces a working system or an expensive experiment.

What does the business need?

Start from the solution: what the business needs to be able to do, not what technology makes possible. The solution is a business priority, not a technical one. It is defined by which processes matter, where the friction is, what good outcomes look like in this organisation, with these clients and these regulatory obligations. Technology choices follow from that understanding.

A strategy that begins with a technology selection is working in the wrong order, and the consequences show up later: pilots that cannot be operationalised, capabilities that do not connect to anything that matters, investments that produce activity rather than outcomes.

The organisations that get this right treat the initial diagnostic as real work. Not a workshop. A structured examination of how the business actually operates, where the burden falls and what solving it would require architecturally.

What is our data position?

Most AI strategies encounter the data problem after the strategy has been committed to. The question belongs at the start. What data does the organisation have, in what state, and where is it? Is it structured or unstructured, centralised or scattered across spreadsheets and systems that do not talk to each other? What would need to be true about the data for the intended automation to work?

The answers determine what is achievable in what timeframe. A strategy built on a realistic assessment of the data position is far more likely to deliver than one that assumes the data will be ready when it is needed.

What do we know, and how do we make it operational?

Automated systems are only as good as the knowledge encoded in them. That knowledge lives in the heads of experienced people who often find it difficult to articulate. Getting it into the system requires a deliberate process: structured conversations, careful formalisation, direct participation from senior people who understand the work. This is as much an organisational challenge as a technical one.

The people whose work is being automated are often also the people who hold the knowledge the system needs. That creates a challenge that is easy to underestimate. Systems built from documented processes rather than from how work actually gets done tend to discover the gap at the worst possible moment. The knowledge extraction process needs to begin early and involve the right people.

Where do we start?

Automation compounds. The firms that will hold the strongest positions in five years are not necessarily the ones moving fastest now: they are the ones sequencing deliberately, building capability that accumulates rather than deploying point solutions that have to be replaced.

The right starting point is where the process burden is highest and the consequences of error are lowest. Operations, compliance, investor communications: high volume, well-understood, rule-governed work that is laborious to run manually. Automating this layer does two things simultaneously: it frees capacity and it builds organisational confidence in automated systems. That confidence is what allows scope to expand toward higher-stakes work over time.

The firms that skip this and go straight to the analytical core tend to discover that their data does not work, their knowledge is not organised and their people are not ready. The sequence matters.

What can we do that we currently cannot do at all?

Efficiency is the obvious benefit of automation: the same work done faster, with less manual effort. But the more significant opportunity is capacity expansion: work that the organisation could not do before, at a scale that was previously impossible.

A manager running a manual investor communications process can maintain a certain depth of relationship with a certain number of investors. An automated system changes both numbers. The same logic applies to opportunity triage, compliance surveillance, portfolio monitoring. The question worth asking is not just where automation saves time, but where it opens territory that was previously out of reach.

What does governance look like?

The firm's existing governance frameworks were designed around human decision-making. A person makes a call, owns the outcome, can be held accountable. Automated systems distribute that decision-making across workflows, agents and models, and the governance framework has to follow.

Which processes require human oversight? How is authority delegated to automated systems? How does the firm demonstrate control to regulators and investors? These questions require explicit answers before deployment, not after.

Established governance functions: risk committees, compliance frameworks, model risk management, provide a foundation, but they were designed for a different problem. They tend to treat AI systems the way they treat vendor software: assessed at procurement, then trusted to run. That is not sufficient.

The knowledge dimension is equally consequential and less often addressed. What an agent can know shapes its outputs as directly as what it is authorised to do. The knowledge made available to an agent: what it can retrieve, what context it operates within, what it is permitted to reason over, is a governance surface in its own right. Governing an automated organisation means governing both dimensions explicitly.

Who is accountable when something goes wrong?

Governance frameworks establish controls. Accountability frameworks establish who answers when the controls are not enough. These are different questions and both need answers before an automated system goes into production.

When an automated workflow produces a bad output: a miscommunication to an investor, a missed compliance obligation, an erroneous trade instruction, who is responsible? How is that determined? What is the process for investigation, remediation and disclosure? These are not hypothetical questions. They are questions that regulators are beginning to ask, and that boards will ask when something goes wrong.

Accountability cannot be distributed to the system. It remains with people. The design of an automated system should make it clear at every consequential decision point who is accountable for the outcome, and the system should produce the evidence needed to support that accountability.

What kind of people do we need?

Automated organisations suit systematically minded people. The processes are explicit, the workflows are defined, the knowledge is encoded: that environment rewards those who can configure, administer and interrogate automated systems, understand when outputs look wrong and know how to intervene. It is a different kind of analyst. A different kind of operations person. Hiring profiles change. Training changes. Over time, the culture changes.

This is not a problem to be managed. It is an opportunity. The firms that recognise it early build teams that compound in capability alongside their systems.

What becomes commercially possible?

Operational capability shapes what a firm can offer. A manager that can assess opportunities faster, respond to investors with greater depth, monitor compliance continuously and report with more granularity is a different firm commercially. It can serve clients it previously could not afford to serve. It can take on mandates it previously could not handle. It can differentiate on the quality of its operational infrastructure in ways that are visible to sophisticated investors and hard for competitors to replicate quickly.

AI strategy and product strategy are the same conversation. Firms that treat them separately end up with operational capability that does not translate into commercial advantage.

What do our clients and investors need to know?

The governance question faces inward: how does the firm control what it has built? The external question faces outward: how does the firm account for what it has built to the people who depend on it?

Investors and clients are increasingly asking about AI use. Some want assurance that the firm's processes are controlled and its outputs are reliable. Some want to understand what decisions are being made by automated systems and what oversight exists. Regulators are moving in the same direction.

The firms that answer these questions well are the ones that built their systems in a way that makes the answers available on demand: not reconstructed from memory, not approximated from a survey, but produced directly from the system itself.

How do we know it is working?

An automated system that is running is not necessarily a system that is working. Output quality can degrade without obvious failure. Agents can produce plausible-looking results from degraded knowledge. Workflows can complete successfully while the outcomes they produce drift from what was intended.

Measurement needs to be designed in from the start. What does good output look like for each process? How is that assessed, and by whom? Where does human review sit, and what does the reviewer actually check? What signals would indicate that something is wrong before it produces a visible failure?

Observability is not a feature to add later. It is a requirement that shapes how the system is built.

How do we build to evolve?

The technology is changing. The regulatory environment is changing. The business is changing. A system designed for today's AI landscape will need to accommodate capabilities that do not yet exist, regulatory requirements that have not yet been written and business priorities that have not yet been identified.

Build to evolve: composable systems, explicit versioning and the discipline to keep the architecture clean as scope expands. Systems that cannot evolve get replaced. Replacement is expensive and disruptive in ways that compounding systems are not.

What does it cost to run?

Every technical decision in this space has an economic dimension as consequential as its technical one. Frontier AI models are powerful and expensive. Many tasks are better served by smaller, cheaper, faster, more specialised models: classifiers, embedding models, time series models, that do their specific job with more precision and at a fraction of the cost. Infrastructure choices carry the same logic.

The discipline to match the model to the task rather than default to the most capable available tool is one of the clearest differentiators between AI deployments that are economically sustainable and those that are not. Procurement relationships, vendor commitments and the pull toward being seen to use the most advanced technology push consistently toward overspecification. A strategy that does not include an economic model is not a strategy: it is a capability wish list.

How do we recover when things go wrong?

Things will go wrong. The question is whether the system is designed to surface failures, contain their consequences and recover cleanly: or whether failures propagate silently until they produce an outcome that is difficult to explain.

That requires an immutable record of what happened, what the system knew at the time and what it decided. It requires knowing which actions carry sufficient consequence to warrant human review before completion. It requires that escalation paths to human oversight are designed in from the outset, not added later when something has already gone wrong. A system that cannot recover cleanly and cannot explain what happened is a system that cannot be trusted: and cannot be governed.

Foundational Principles

The solution

Work at the solution level. The tools, the agents, the workflows, the infrastructure are the parts. The solution that coordinates them is the primary abstraction. It is the thing we build and the thing we manage. Working at the solution level is the frame from which every design decision follows.

Describe the solution fully. A solution that is fully described can be reproduced exactly, on any infrastructure, at any time. It can be evolved deliberately, because every change is explicit and versioned. It can be owned completely, because the knowledge of how it works lives in the system itself. Reproducibility, evolvability and ownership are engineering requirements.

Get the abstractions right. The concepts used to model a system determine whether it remains comprehensible and maintainable as it grows. Concepts that carve the problem at its joints produce systems that can be reasoned about and evolved. Once established, the discipline is to keep abstractions properly bounded: composition, execution and infrastructure each addressed at the right level.

Compose declaratively, provision dynamically. The solution is expressed as declared intent: what it should be, rather than instructions for assembling it. The system reconciles that intent against actual state. Infrastructure is brought into existence as part of the solution, provisioned in the same composable way as everything else.

Models and AI

Know the full AI landscape. AI is a much larger category than large language models alone. Embedding models for semantic search and document similarity, classifiers for document triage and categorisation, time series models for market data and signal generation, speech models wherever voice is an input or output. Each addresses a class of problem with more precision and economy than a general-purpose LLM. The discipline is to match the model to the problem.

Choose the right point on the spectrum. Business process automation spans a wide range: from deterministic quantitative pipelines, fast, reproducible and economical, through to fully agentic processes where an AI reasons about what to do next. Most valuable business processes sit somewhere in the middle, or combine elements from across the spectrum. The right approach for each process is chosen deliberately.

Treat trade-offs as economic decisions. Cost, value and efficiency are dimensions of technical decisions. Which AI model to use, how to provision infrastructure, where to place human oversight: each is simultaneously an engineering decision and an economic one. The right choice for each task is made deliberately, with technical and economic dimensions treated as inseparable.

Knowledge

Extract organisational knowledge. Building an automated system requires making tacit organisational knowledge explicit, an organisational process as much as a technical one. Experienced people often carry knowledge they cannot readily articulate. Getting it into the system requires direct participation from the senior people who hold it. LLMs are useful at this stage as structured interlocutors, drawing out and formalising knowledge that practitioners find difficult to articulate unprompted.

Get the ontology right. Ontology, in this context, refers to the structured vocabulary of concepts a firm uses to think about its domain: the categories, dimensions and relationships that define how it classifies opportunities, counterparties, risks, strategies and other domain objects. Getting the ontology right determines what context an agent can retrieve and how precisely. Surfacing and formalising the right ontology is part of every engagement.

Defend the feedback loop. Outputs that leave the system and outputs that re-enter it as knowledge are two distinct classes. The second introduces a feedback loop: good outputs compound value; poorly reasoned outputs degrade future reasoning. Outputs re-entering the system require a higher standard of validation. Confidence gating holds outputs below a quality threshold for human review. Provenance tracking records which knowledge informed each output. Together they ensure that what the system learns from can be trusted and traced.

Govern what agents know. What an agent can do is a governance concern. What an agent can know is equally consequential. The knowledge made available to an agent, what it can retrieve, what context it operates within, what it is permitted to reason over, determines the quality and appropriateness of its outputs as surely as its authority to act. Both are governance surfaces. Both are designed explicitly.

Agent design

Decompose the problem. AI models reason better on constrained, well-defined problems. The right approach is to decompose: frame the problem, plan the approach and execute each step as a separate focused task with tight, relevant context. Smaller, well-scoped problems produce more reliable outputs from AI models of all kinds.

Choose agent topologies deliberately. Multi-agent systems can be organised as hierarchical, collaborative or competitive topologies. Hierarchical suits problems with clear sequential structure. Collaborative suits problems that benefit from multiple viewpoints, with outputs synthesised. Competitive suits problems where quality matters more than efficiency. A solution will typically employ several topologies, each chosen for the structure of the problem it addresses.

Calibrate autonomy to consequence. The degree of autonomy granted to a workflow or agent is proportional to the consequences of error. Processes that act irreversibly and with significant consequence, such as committing capital, communicating with clients or triggering regulatory obligations, require human review before completion. This calibration is a first-class design concern, made explicit and configurable from the outset.

Start at the edge, move to the core. Automation typically begins in operations: high-volume, well-defined processes that carry limited consequences of error. The value is real: freeing capacity, improving consistency and building confidence in automated systems. Over time, as capability and trust accumulate, automation moves closer to the investment process itself, where the consequences of error are more significant and the governance requirements more demanding.

Systems

Design for distributed systems at scale. Modern solution development is distributed systems work. Services communicate over networks, operations take time and fail unpredictably, state lives in multiple places. The systems we build are designed for this reality throughout, and for the full range of operational scale, from carefully sequenced human-reviewed workflows through to massive parallelisation across large datasets.

Version everything, make systems observable, ensure execution is durable. Every component of the solution carries a version and the full state of a solution is reproducible at any point in time. Every operation produces a record, every state change is traceable, history is preserved and audit is built in. Workflows survive failures, restarts and infrastructure changes without losing state. Observable, versioned, durable systems can be trusted, governed and improved.

Platform Architecture

Ergon does the work. Daedal governs. Both are the product of years of focused work on the specific problems of business process automation at institutional scale.

Ergon

Ergon supports the full spectrum of workflow patterns from deterministic pipelines through to fully agentic processes, and the combinations of both that most real business processes require.

Ergon is a modular system. Its modules cover workflow orchestration, multi-agent coordination, knowledge management, quantitative pipelines, internal messaging and inter-agent communication, user interfaces and integrations with external systems. Each module is designed to work as part of a coordinated whole. Every process moves through the same lifecycle: invocation, state management, failure handling and completion. Ergon handles each stage consistently, regardless of where on the deterministic-agentic spectrum a workflow sits.

Workflow execution

Durable workflow execution is handled by Restate. Restate provides exactly-once execution semantics, durable function calls and built-in recovery — workflows survive failures, restarts and infrastructure changes without losing state. Every workflow step is journalled, making the full execution history of any process inspectable and auditable.

Messaging

Redpanda or Kafka is the messaging backbone. It carries both internal system events and inter-agent communication, providing durable, ordered, high-throughput message delivery across the platform. Agent coordination, workflow triggers and integration events all move through Kafka, giving the system a single observable channel for everything in flight.

Knowledge management

The knowledge layer assembles and delivers context to agents and workflows. Structured data lives in Postgres. Documents and content artefacts are stored in S3-compatible object storage. The retrieval layer draws on both, assembling well-structured context packages for each agent invocation. The knowledge that flows into Ergon — agent directives, workflow definitions, ontologies, AI model configurations and domain-specific content — is treated as client content from the outset.

Infrastructure

Ergon runs on Nomad. Nomad provides flexible, lightweight workload orchestration across diverse infrastructure — cloud, on-premises or hybrid — without the operational overhead of Kubernetes. Ergon's workloads are scheduled and managed by Nomad, giving deployments a consistent operational model regardless of the underlying infrastructure.

Daedal

Daedal is the solution composition system, the foundational layer beneath Ergon. It addresses how a distributed solution is assembled from versioned, coherent packages, how those packages are configured relative to each other and how the whole thing is managed, evolved and reproduced over time.

Daedal is used internally by Operative Solutions to build and manage the systems it deploys. Its CLI is daedal. Daedal is open source.

Ecosystem

The knowledge that flows into Ergon includes agent directives, workflow definitions, ontologies, AI model configurations and domain-specific content. It comes from multiple sources: developed collaboratively with the client, contributed by Operative Solutions and drawn from specialist third-party providers as that ecosystem matures. Ergon is designed to receive and coordinate content from all of these sources.

Licensing

Operative Solutions believes in open source for substantive reasons: transparency, auditability, avoiding lock-in and the compounding value of shared infrastructure. Daedal is open source. As infrastructure that sits below the business logic, it benefits from community scrutiny and builds trust.

Ergon is proprietary. Ergon encodes how each client works. The system as deployed is part of the client's competitive position. Clients receive an enduring, irrevocable source licence — full access to and ownership of the code running in their environment. Their rights to the code are permanent and unconditional.

The content that runs on Ergon — agent directives, workflow definitions, ontologies and domain knowledge — is treated as client content from the outset. Whether developed by the client or produced by Operative Solutions under its engagement arrangements, that content belongs to the client. No separate licence is required: copyright vests with the client as the content is created.

Some engagements require Ergon to integrate third-party software or content. Where those integrations carry their own licence requirements, those are identified during engagement scoping and managed as part of the solution design.

Use Cases

An investment management firm runs on processes: communicating with investors, managing operations, making investment decisions and running the business behind them. Each of these generates significant workload, much of it repetitive, document-heavy and consequential.

Use cases are the specific processes within each of these areas that are candidates for automation. Not automation in the abstract — but particular workflows, with particular inputs, particular outputs and particular people in the loop.

Investors

The investor-facing side of an investment management business runs on communication – with existing investors, prospective investors and the intermediaries between them. The volume is significant, the stakes are high and the work is time-consuming.

Investor targeting and prospect research: building and maintaining a structured picture of the market, identifying firms that match the manager's capital raising criteria, tracking engagement across the pipeline and surfacing the right moment to reach out.

Pitch deck and marketing material production: assembling, drafting and version-controlling materials that reflect current positioning and performance. Maintaining consistency across a library of materials as the firm's strategy, performance and team evolve is itself a significant task.

Roadshow coordination: managing logistics, preparing briefing materials tailored to each meeting and handling follow-up systematically across a programme of investor engagements. Relationship context captured and carried forward.

Investor communication and reporting: maintaining a consistent and well-timed cadence with existing investors, producing performance reports, portfolio updates and quarterly letters to a consistent standard on schedule, with human review focused on exceptions and client-specific commentary.

RFP and DDQ responses are where the depth of the organisation is most directly tested. A coordinated set of agents – covering investment process, compliance, risk, operations and firm history – brings the full depth of the organisation to every response. An editorial layer ensures consistent voice and positioning throughout. Response quality that previously required days of senior time can be produced in hours, with senior review focused on substance rather than assembly.

Capital call and distribution notices, mandate and mandate change documentation, regulatory communications to investors – each generated accurately and distributed with the supporting documentation required.

Operations

Investment management operations involve a significant volume of process work that is well-understood, rule-governed and consequential. Trade settlement exception handling, reconciliation workflows, counterparty onboarding, NAV sign-off processes and mandate guideline monitoring – each is a candidate for automation that reduces manual effort and improves consistency.

Compliance monitoring sits alongside operations: continuous surveillance of portfolio positions against regulatory constraints and internal risk limits, with potential breaches identified, assessed for materiality and routed through the appropriate process. Regulatory reporting and audit trail generation are natural companions. When a potential violation is identified, a coordinated workflow can gather the relevant context, assess its materiality, draft the required communications and route for human sign-off before anything leaves the firm.

Corporate actions processing is another area of significant operational load: identifying relevant events, assessing portfolio impact, generating instructions and tracking through to settlement. The volume at an active manager is substantial and the consequences of errors or missed deadlines are real.

Investing

The analytical core of an investment management business is where the most demanding and most valuable automation opportunities sit.

Deterministic pipelines of composable analytical functions handle signal generation, factor analysis, portfolio optimisation and risk modelling – running with precision and auditability, feeding results into workflows and agents across the system. These pipelines are reproducible, versioned and auditable: every output traceable to the inputs and logic that produced it.

Multi-agent networks traverse large datasets to surface correlations, patterns and anomalies that inform investment decisions. The scale at which agents can operate – across news feeds, filings, pricing data, alternative data sources – is qualitatively different from what an analyst team can cover manually.

Predictive models for market behaviour and portfolio construction sit alongside these pipelines, available to analysts and portfolio managers as a structured starting point. Model outputs feed directly into workflow steps rather than sitting in separate tools.

Inbound opportunity management: classifying, prioritising and routing broker research, deal teasers, fund prospectuses and direct approaches – and producing a structured first-pass assessment for anything that merits it. Automating triage and initial analysis, with portfolio fit modelling included as standard, means analysts start each day with a prioritised queue and a structured brief.

Investment committee paper preparation: aggregating material from across the firm, drafting structured sections, routing for review – with the analyst focused on the substance of the recommendation rather than the mechanics of assembly.

Portfolio monitoring and exception reporting: continuous surveillance of positions against investment guidelines, concentration limits, liquidity constraints and risk parameters, with exceptions surfaced, contextualised and routed for action.

Holistic

The same platform and approach applies wherever a business has complex processes to coordinate.

Corporate communications: board papers, regulatory filings, stakeholder communications, media monitoring and response. The discipline of coordinated agents drawing on current and accurate organisational knowledge applies here as directly as it does to investor communications.

HR workflows: recruitment coordination, onboarding, performance processes, policy management and maintenance. Organisations that have encoded their processes and knowledge into automated systems need people who can work within those systems – the hiring profile changes and the onboarding process can reflect that.

IT operations: help desk triage and first-line resolution, incident management, change management, vendor and contract management. Systematic organisations generate systematic IT requirements.

Knowledge management: document classification, meeting notes and action tracking, institutional memory capture. The knowledge that accumulates in an organisation over time is one of its most valuable assets and one of the least systematically managed. Automated systems that continuously capture, classify and surface institutional knowledge compound in value over time.

Governing Intelligent Systems

Every board has AI on the agenda. Most are anxious about it. Many feel they are already behind. All share a problem that neither has fully solved: they do not know, with confidence, what AI they are actually running.

This is not unusual. It is the norm. Someone in the finance team found a useful tool. Someone in compliance is using something else. IT has an approved software list that does not capture half of what is actually in use. The picture that risk and compliance functions hold is always somewhat behind reality, and it is getting harder to close that gap as AI tools proliferate.

Regulators have noticed. ASIC and APRA are not yet demanding answers, but they are asking questions, and the questions are getting more specific. What systems are making decisions that affect clients? What oversight exists? How would you know if something went wrong?

How organisations are responding

The most common response is the staff survey. Quarterly, sometimes more often, someone goes around and asks people what AI tools they are using. It is time-consuming, it captures perhaps a third of what is actually happening, and by the time it is complete the picture has already changed. It produces a document. It does not produce governance.

The obvious improvement would be a register that populates itself, with every tool reporting into a central record automatically so the picture is always current. The problem is that this would require every tool to speak a common language and report through a common hierarchy. No such standard exists. The tools do not agree. The picture would only be as complete as the tools chose to make it. Most have no reporting mechanism at all, and those that do typically surface very little about what they know or what they are permitted to do.

Which is where the deeper problem starts.

Four governance surfaces

Governing an automated system properly means accounting for four governance surfaces, each one a layer where control either exists or does not. These surfaces apply to any automated system. AI makes the stakes more visible and the gaps more consequential.

Constitutional: What is it? What is running, where and in what way? Every component of an automated system: what it is, what version, where it is deployed, how it is configured, what it connects to and what it has been told to do. The complete assembled picture of the system as it actually runs, current and authoritative. This is the question most organisations are grappling with right now. The survey exists because of it. The survey fails because it is disconnected from the systems themselves.

Authoritative: Who does it? Who defines it, who builds it, who operates it, who uses it, how is authority delegated, and who is accountable for it? Who commissioned each component, who approved it, who is responsible for its ongoing operation. What mandate it operates under and what the limits of that mandate are. Authority originates with people — the stakeholders, governance bodies and operators who determine what the system is permitted to do — and flows through to the workflows, agents, workloads and end users that act within it. What data and knowledge each part of the system is authorised to access is determined by the people who govern it.

Epistemic: What does it know? What data and context does it draw on? The data and context that workflows and agents draw on: what they can access, what knowledge they reason from, what context gets assembled for each task, what sensitive information they hold or retrieve. Most organisations have no governance over this at all. They provide documents and data to automated systems without a review process and assume the outputs will be reliable. When outputs are unreliable, the conclusion tends to be that AI does not work. The more accurate conclusion is that ungoverned inputs produce ungoverned outputs.

Executory: What can it do? What actions can it take and with what consequences? The boundary between a system that informs decisions and one that takes them. What the system can do, what real-world effects it can produce, what confidence is required before it acts and where human review sits in the chain. This is the surface that regulators are beginning to focus on most sharply, and for good reason. Most AI deployments do not draw this line clearly.

Boundaries are governance surfaces

Every boundary a system crosses is a governance surface. Data flowing in, services called out to, outputs crossing into the world: each is a point where the four questions apply as directly as they apply to the system itself.

The boundaries organisations face are varied. Legacy company data brought into a knowledge store. Third-party data providers whose content feeds agent reasoning. Frontier AI models called at runtime as a service. Broker and exchange connections carrying consequential instructions. Investor interactions generating obligations. Corporate filings crossing into the regulatory domain.

Each of these crossings has a constitution. What is crossing, in what form, under what configuration. Each has an authority. Who approved it, under what mandate, what the system is permitted to send or receive. Each has an epistemic dimension. What knowledge or data is being introduced, and with what provenance. Each has an executory dimension. What consequences follow from the crossing.

The data problem many organisations encounter when they first attempt automation is a boundary problem. Data that exists inside the organisation sits outside the governed system until it is brought in. It arrives raw, unclassified, in formats suited to human use rather than automated processing. Governing the ingestion process, treating it as an automated system subject to the same four surfaces, is the starting point.

Declaring the system

The approach that works starts from a different premise: governance is a property of how a system is built, not something maintained alongside it. This means declaring the system — every component, every agent, every workflow specified before it runs, as the specification the system is actually built from. The running system is built from that specification and held to it. When something changes, the specification changes first.

This answers each of the four governance surfaces directly.

Constitutional. The declaration is the register, and it is always current. Nothing runs that is not declared. A declared system carries that information within itself. The question of what is running is answered by the system, not by asking around.

Authoritative. The declaration records who commissioned each component, who approved it and under what mandate. The full chain of authority — from the governance bodies and stakeholders who granted it, through to the workflows, agents and users it was conferred on — is in the system, explicit and traceable. When something goes wrong, that record is available on demand.

Epistemic. The knowledge that workflows and agents reason from is a governed asset within the same framework. Documents are reviewed and approved before they reach agents. There are controls over what gets assembled as context for a given task, and at what level of confidence. If an agent produces output that requires scrutiny, you can trace exactly what it was working with: which documents, approved by whom, at what point in time.

Confidence compounds. Low-confidence inputs, reasoned over by an agent operating below full confidence, produce outputs whose reliability is lower than either alone. Each step in the process can look plausible in isolation. The problem is only visible when you can see the whole. Confidence thresholds can be set across the full chain, and compounding problems can be identified before they produce a bad output.

Executory. The boundary between reasoning and action is enforced by the architecture. Agents observe, analyse and produce output. Consequential actions pass through a controlled layer where human review can be required, below a confidence threshold the organisation sets. A structural constraint is a better class of guarantee than a policy.

What to demand of a governed system

Any organisation deploying automated systems should be able to answer a clear set of questions on demand, without a survey, without reconstruction from memory.

Recovery. The full state of the system at any point in time should be reproducible. If something fails, restoring it should be a matter of applying a complete specification to a clean environment. Point-in-time recovery for an entire automated system is not an aspirational capability. It is a baseline requirement.

Visibility. The system should be queryable as a whole. Where are confidence levels compounding across the system in ways that produce unreliable outputs? How does a change to one agent propagate through the workflows that depend on it? What is the full chain of reasoning and knowledge behind a particular output? If these questions cannot be answered, the system cannot be governed.

Accountability without reconstruction. When something goes wrong, the record of who authorised what, under what mandate, with what knowledge, should be in the system. The chain of authority and the chain of reasoning should be traceable from the system itself.

Growth without loss of control. As the system grows, governance should grow with it. Each addition should be governed from the start, on the same terms as everything else. A system that requires governance to be retrofitted as it scales is a system that will lose governance as it scales.

The questions worth asking

The governance frameworks being developed by ASIC, APRA and international equivalents are converging on the same ground. The organisations that will answer them well are not necessarily the ones with the most thorough policies. They are the ones that built their systems in a way that makes the answers available on demand, without a survey, without reconstruction from memory.

What is it? What is running, where and in what way? Who does it, and who is accountable? What does it know and what data does it draw on? What can it do and with what consequences?

These are not difficult questions to ask. They are difficult to answer without a system that was built to answer them. Is governance a property of the system, or something maintained separately alongside it? That is the question worth asking before any other.

People

Lachlan Douglas

Richard Heycock

Engagements

Scope

Strategy

Intellectual Property

Clients

Practice

Principles

Technology