Skip to content
Free AI Benchmark — see where you are exposed before you deploy AI.Start the benchmark

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

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

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
Developers/SDKs & Examples

Build against MergeOn once. Keep the business contract stable as AI changes.

Your application targets a published Business Capability in a governed Runtime — not a model endpoint. MergeOn keeps knowledge, policy, protection, human authority, permitted AI participation and evidence around that operation, so those responsibilities do not have to be rebuilt into every application.

The application calls the business activity. MergeOn governs how it is fulfilled.

MergeOn integration pattern
Business application
MergeOn Business Capability
Governed Runtime
KnowledgePolicyProtectionHuman Approval
Permitted AI / agent / tool / system
Declared outcome
Golden Thread
Conceptual MergeOn integration pattern — not an SDK or API sample.
What you are addressing

What every MergeOn integration is actually targeting.

A MergeOn integration is not a wrapper around a model call. The caller identifies governed business work; MergeOn resolves that work inside the Runtime boundary under the published execution state.

Runtime

The governed operating boundary responsible for the activity.

Environment

The environment in which that Runtime is being used.

Published Business Capability

The business activity the application is permitted to invoke.

Declared input

Structured business input matching that capability's contract.

Governed execution

The operation created and governed by MergeOn.

Declared outcome + execution identity

The business result the caller consumes, and the operation identity retained for evidence.

You target business work. MergeOn resolves the governed execution behind it.

Reference pattern 01

Invoke a published MergeOn Business Capability.

The application does not select a model and ask it to perform arbitrary work. It targets business activity that has already been defined and published through a governed Runtime.

01Target

Runtime and environment.

02Select

Published Business Capability.

03Supply

Structured input matching the declared contract.

04Govern

MergeOn applies the knowledge, policy, protection and authority conditions belonging to that activity.

05Execute

The permitted participant performs the bounded activity.

06Return + retain

The declared business outcome is returned while execution identity remains connected to the governed operation.

Call the capability. Do not wire the application to the model behind it.

Reference pattern 02

When MergeOn refuses execution, the control plane is doing its job.

A MergeOn request can satisfy its business contract and still be refused because the governing conditions for that activity do not permit execution. That is materially different from malformed input, unavailable infrastructure or an unexpected system failure.

RequestContract validGoverning conditionRefused
Not this
  • Malformed input
  • Unavailable infrastructure
  • Timeout
  • Unexpected system failure
A governed refusal
  • The business contract was satisfied
  • A governing condition did not permit execution
  • MergeOn behaved correctly
  • The activity's conditions must change before it can proceed

A governed refusal is an execution result, not permission to bypass the control.

Reference pattern 03

Human Approval is part of the MergeOn execution path.

Where a Business Capability requires human authority, the application request does not grant itself permission to complete the operation. MergeOn holds the governed activity at the authority boundary until the authorized decision is made.

Application requestMergeOn RuntimeAuthority requiredAuthorized personContinue / refuse

The application requests the work. The authorized person grants the authority.

Reference pattern 04

Change the AI participant behind the Runtime — not the application contract.

The application continues to depend on the same published Business Capability while the permitted AI participant can change behind the Runtime boundary. Knowledge, policy, protection, authority, tools, declared outcome and evidence remain attached to the governed activity rather than to a provider-specific integration.

ApplicationPublished Business CapabilityGoverned Runtime
Current
Model A
Later
Model B

A replacement probabilistic participant remains subject to qualification and evaluation before participating in the governed activity.

Swap without rebuilding. Re-qualify without starting again.

Reference pattern 05

Connect enterprise systems without transferring their authority to AI.

CRM, ERP, finance, HR, identity, document repositories and operational systems remain authoritative for the facts and actions they own. MergeOn governs how the AI-enabled Business Capability interacts with those systems; it does not turn the model into the system of record.

Business applicationMergeOn RuntimeEnterprise capability / toolSystem of record

Integrate the system. Keep its authority where it belongs.

Reference pattern 06

Give the Runtime accepted enterprise context — not application-specific RAG plumbing.

MergeOn Document Intelligence can transform source material into Tier-3 Review Packs that preserve meaning, relationships, dependencies, source context and provenance. Once reviewed and accepted, that material can become Governed Knowledge available to the Runtime activity that needs it.

Source documentsDocument IntelligenceTier-3 Review PackGoverned KnowledgeRuntime activity

The application requests the business activity. It does not have to reconstruct the organization’s accepted context independently on every integration.

Govern the knowledge once. Supply it where the activity needs it.

Reference pattern 07

Keep the business result connected to its Golden Thread.

The application may only need the declared outcome immediately. The organization may later need to establish which Runtime and published release ran, what governed knowledge and controls participated, whether human authority was required, which participant executed and what outcome followed.

What the application consumes
RequestGoverned executionDeclared outcome
What MergeOn retains
Execution identityGolden Thread

Return what the application needs. Preserve what the organization needs to prove.

The pattern to reuse

The reusable MergeOn application pattern.

Different applications may call different capabilities, use different languages and connect different enterprise systems. The operating pattern stays recognizable: business activity is declared, execution is governed, authority remains explicit and evidence remains connected to what actually happened.

Application
Published Business Capability
Governed Runtime
KnowledgePolicyProtectionAuthority
Permitted participant
Declared outcome
Golden Thread

A client implementation may differ by language. The MergeOn business contract does not.

That is the pattern to reuse.

Outside your codebase

What MergeOn keeps outside the application’s codebase.

Six responsibilities that would otherwise land in every application that talks to a model, each one reimplemented slightly differently and each one drifting from the others over time.

Model selection

The application depends on the Business Capability, not a provider-specific implementation.

Governed knowledge

Accepted enterprise context belongs to the governed activity.

Policy

Execution conditions are not reimplemented independently by every caller.

Protection

Application access does not automatically become model access.

Human authority

Required approval remains an explicit part of execution.

Evidence

The governed operation retains its Golden Thread.

Your application owns the experience. MergeOn owns the governed execution boundary.

Build the business capability once. Let the AI implementation change behind it.

MergeOn gives applications a stable governed business boundary while models, providers and implementation choices evolve behind the Runtime.