The MergeOn Platform
The enterprise foundation for building, governing and operating AI at scale.
Explore the platform →THEMIS Mission Control NewUnderstand what is changing across your organization and bring the right decisions to the right people at the right time.
Runtime Digital Twin PreviewVisualize every runtime, capability and relationship across your AI operating environment.
Create governed AI activity once, with its knowledge, controls, approvals and execution requirements.
Runtime CenterOperate and observe governed Runtimes, activity, execution, evidence and readiness from one operational surface.
Governed KnowledgeTurn enterprise information into structured, governed context that AI can use without losing source meaning and relationships.
Policy & ProtectionDefine the controls that govern what AI may access, what it may do, what must be protected and when a person must approve.
Data ProtectionProtect sensitive values while preserving the business context AI needs to perform the governed task.
Human ApprovalRequire human authority where governed AI activity should not proceed on AI authority alone.
Golden ThreadReconstruct governed AI execution from request to outcome with connected execution evidence.
AI Evaluation & AssuranceVerify what can be proven, evaluate AI behaviour and establish evidence-backed readiness in context.
AI Model GovernanceGovern which models may participate, where they may be used, what evidence supports them and when their qualification must be reconsidered.
Why MergeOn
Turn the knowledge you already have into governed context AI can use.
Policies, procedures, manuals, regulations and operating documents were written for people — not AI.
MergeOn Document Intelligence transforms them into structured Tier-3 Review Packs, preserving meaning, relationships, dependencies and source context. Accepted knowledge can then be governed in the Knowledge Center and supplied to AI at execution.
Better context. Less repeated processing. More efficient AI execution.
Explore Governed Knowledge →Wherever critical knowledge, policy and AI execution have to work together.
Govern policies, controls, product rules and regulated decisions while keeping AI execution traceable.
Healthcare & Life SciencesTurn clinical, operational and regulatory knowledge into governed context while protecting sensitive information.
Logistics & Supply ChainStructure customs, trade, food, agriculture, transport and supplier requirements so AI can work from the right rules for the activity.
Legal & Professional ServicesTransform contracts, precedents, policies and matter knowledge into governed context with source-level evidence.
Industrial & Critical OperationsGovern procedures, technical documentation, safety requirements and operational knowledge across complex environments.
Public Sector & Defense Supply ChainControl how sensitive policy, procurement, compliance and operational knowledge participates in AI-enabled activity.
Build on MergeOn
The application asks for a business outcome. The Runtime governs how it is produced.
An integration calls a published Business Capability rather than a model endpoint, so knowledge, policy, protection, human authority and evidence stay part of the activity instead of becoming your problem to rebuild.
Everything below describes the contract you build against and the architecture behind it.
Explore the developer platform →Everything you need to integrate, extend and build on the MergeOn platform.
API ReferenceComplete REST APIs, authentication, schemas and integration endpoints.
SDKs & ExamplesAccelerate development with SDKs, sample applications and reference implementations.
Technical documentation covering platform architecture, configuration and deployment.
Integration GuidesStep by step guides for connecting AI providers, enterprise systems and business applications.
Architecture PatternsReference architectures and implementation patterns for enterprise AI deployments.
Know where you stand
Most organizations do not have an AI problem. They have a clarity problem.
Before deciding what to build, it helps to establish what your organization already believes about ownership, governance and decision-making — and where those beliefs disagree with each other.
Start with an honest read of where you are. Everything else follows from it.
Start the free benchmark →Take the free 12-question benchmark and get an immediate view of your organization’s AI readiness.
Start the benchmark Leadership Alignment AssessmentCompare leadership perspectives to reveal where your team is aligned, where views diverge and where that difference matters.
Explore the assessmentMergeOn was created to give organizations a governed foundation solid enough to put real AI-enabled work on.
Read our story →Why MergeOn exists and how we are building the enterprise control plane for governed AI execution.
CareersJoin the team building the control plane for governed enterprise AI.
Contact UsTalk to MergeOn about your organization, implementation or enterprise AI programme.
See how the models, cloud, data and enterprise technologies organizations already use can participate in governed MergeOn execution.
Implementation PartnersBuild a governed AI practice on MergeOn and help enterprises move from AI pilots into controlled production.
Become a MergeOn Implementation PartnerBring MergeOn into client engagements, build repeatable governed AI capability and register for partner enablement and future certification.
Integrate with the governed business contract — not the model behind it.
MergeOn separates the application contract from the AI participant that fulfils it. Requests target governed business activity in a published Runtime; models, agents, tools and systems participate behind that boundary under the controls attached to the operation.
The caller asks for business work. The Runtime determines how that work is governed and fulfilled.
Address the activity. Do not address the model.
In a direct model integration the application ends up knowing the provider, the model, the prompt, a model-specific request shape and how to handle its response. Every one of those couples the application to a probabilistic participant that will be replaced before the application is.
In MergeOn the durable integration target is the governed business activity. The caller supplies the declared input. The Runtime resolves which published configuration and which permitted participant fulfil it.
Your application depends on the contract. MergeOn owns the execution boundary behind it.
Runtime, environment, release and capability are different coordinates.
These are the coordinates that specify what a request actually targets. They are routinely flattened into a single idea of “which version”, and that is where most integration confusion starts.
The governed operating boundary the activity belongs to.
The execution context — for example Sandbox, Staging or Production where applicable.
The published executable version of the Runtime configuration.
The declared business activity and contract the caller intends to use.
The individual occurrence of that governed activity.
Do not collapse environment, release and execution into one generic version.
Draft configuration is authoring state. Published configuration is execution state.
Developers need a stable target. A draft keeps changing while the activity is being designed — that is what drafts are for. Governed execution resolves against the published release appropriate to the target environment, rather than whatever the configuration happened to be at the moment of the call.
Authoring state. It can keep changing while the activity is being designed, which is exactly what makes it a poor execution target.
Execution state. An approved version, resolved for the target environment. This is what a request actually runs against.
The record of what ran, including which published release governed it.
Author the draft. Publish the release. Execute the published truth.
Define what the activity accepts and what it promises to return.
A governed capability carries a declared business contract: its purpose, structured input, validation, declared output and execution context. The calling application should not have to read prose out of a completion to work out whether a business operation succeeded.
Business integration needs a contract, not a conversation.
A technically valid request can still be refused.
Admission to execution depends on conditions that sit outside the calling application’s logic. A request can satisfy the technical contract perfectly and still not be permitted to run — and that is the platform working, not the call going wrong.
Valid does not mean authorized.
A system error and a governed refusal are not the same thing.
Three conceptually different outcomes, which naive clients collapse into one “it didn’t work” branch. That collapse is what produces retry storms against decisions that were made deliberately.
The request cannot be processed because the technical contract was not satisfied, or a required service failed.
The request was understood, and a governing condition does not permit execution. Nothing malfunctioned.
The activity cannot continue until the required human authority has acted. It is waiting, not failing.
Do not retry a governance decision as though it were a network error.
This page teaches the semantics. Exact status and code-level contracts belong in the technical reference when it is published, and are deliberately not guessed at here.
Every execution needs an identity that survives beyond the request.
A single enterprise execution can involve the caller, a Runtime, an environment, a release, a business capability, a model or agent or tool, policy, human authority, downstream systems and an outcome. Durable execution identity is what keeps those facts connected once the HTTP request is long finished.
The identity of this occurrence of the governed activity.
What ties related work together across the operation.
Where a chain of governed work began, when one activity leads to another.
Trace the business operation, not just the HTTP request.
Do not accidentally execute the same business activity twice.
Distributed systems retry. Timeouts happen. Clients lose responses they were waiting for. For a business operation, a blind retry is not a free action — it can become a second execution with real consequences.
Retry behaviour has to respect execution identity, and use the idempotency contract of the specific execution surface where that surface supports it. It is not safe to assume idempotency is universal across every surface.
Retry the request without duplicating the business effect.
Approval is not an error response.
Where Human Approval governs an activity, the operation can reach a state in which execution cannot continue until an authorized person decides. A caller that treats that as a model failure, or retries it, has misread governed workflow state as a fault.
The API request can finish before the governed business operation does.
The model does not need every value the caller can see.
A calling application often holds sensitive information that is irrelevant to the AI participant’s task. Protection belongs inside the governed activity, so the execution can preserve the business context the task needs without automatically exposing every original value that happened to be in scope on the caller’s side.
Application access does not automatically become model access.
Do not make every caller rebuild retrieval logic.
When context is the caller’s responsibility, every integrating application ends up implementing its own retrieval, chunking and prompt assembly — each slightly differently, each drifting apart over time. Governed Knowledge lets accepted organizational context belong to the Runtime activity instead.
Knowledge is part of the activity's operating context, not caller-side prompt plumbing.
A business result and its execution evidence are different things.
The caller needs the declared business outcome. The organization also needs the governed record of how that outcome was produced — what was requested, which Runtime and environment applied, which published release executed, what governed knowledge participated, what policy and protection applied, who authorized where required, which participant executed and what outcome followed.
Those are two different consumers with two different needs, and conflating them makes both worse: the caller gets a response it has to parse around, and the organization gets evidence that only exists if someone kept the response.
Return the business result. Retain the operating evidence.
One business operation can involve more than one governed Runtime.
A Primary Runtime can coordinate enterprise activity while Connected Runtimes retain authority over capabilities belonging to their own operating area. For a caller this changes nothing structurally: you depend on the declared capability, never on what the other side does internally to fulfil it.
Cross the boundary through a declared capability, not by reaching around it.
The API, Runtime release and business capability are not the same version.
Four things version independently. Treating them as one is the fastest way to make a routine change look like a breaking one — or to miss a breaking one entirely.
How a caller communicates with MergeOn.
Which published configuration governs execution.
What business input and output the caller depends on.
Which probabilistic participant may currently fulfil the activity.
Changing the model should not automatically become an API-breaking change.
The caller depends on the business capability contract. A qualified participant changing behind that contract is a governance event, not an integration rewrite.Know what your application is actually depending on.
Ten questions worth answering before the first line of integration code. Most production surprises trace back to one of them being assumed rather than established.
Which Runtime owns the activity?
Which environment is being targeted?
What published business capability is the caller using?
What structured input does it accept?
What declared output does it return?
What governance can refuse or pause execution?
Does the operation require Human Approval?
What retry and idempotency behaviour does the specific surface support?
What execution identity should the caller retain?
What evidence belongs to the operation?
From contract to implementation.
Understand the Runtime architecture and why applications target governed business capability rather than model endpoints.
DocumentationUnderstand Runtime, environments, releases, capabilities and governed execution.
Architecture PatternsSee how these contracts compose across enterprise systems and operating boundaries.
Build to a business contract that survives the model underneath it.
Keep the caller stable while Runtime configuration, governed knowledge, controls and qualified AI participants evolve behind the execution boundary.