Your logic stays yours.
Domain algorithms and specialist services run as first-class capabilities, not workarounds.
Developer Extensibility
Your code.
Your capabilities.
One governed application.
Build the parts that make your business different.
Write the logic that sets you apart in your own code. Run it with the same identity, policy, approvals and evidence as the rest of your Frozion application, without building a separate governance layer around it.
Invoice review · AP-Review v7Specialized where it matters.Connected where it counts.
ReceiptCheck.v2Custom deterministic logic
Enterprise APIExisting system of record
Private specialist modelApproved tasks and data
Review componentScoped evidence view
Each capability has an explicit boundary
FROZIONExecution FabricGoverned from request to outcome
The governed applicationTyped contractsAuthority checkedApproved versionsRuntime evidence
Extend with confidenceCustom code & kernelsServices & modelsReusable workflowsSpecialized UI
Your code works on every step
Govern existing agents
Your existing agents can call your proprietary logic, checked and recorded from the first call.
Grow tools into workflows
Your specialist logic becomes a workflow step, with the same rules and approvals around it.
Build native agents
Native agents use your custom capabilities alongside Frozion’s own.
Build systems of engagement
Your own components appear inside apps for employees, customers, vendors and partners, under the same sign-in and permissions.
The problem this solves
Ship custom logic without starting a governance project.
Separate access checks, logs and audit trails can turn every proprietary service into another governance project. Frozion connects your custom capabilities to the controls and record of the application that uses them.
Every call is checked for you.
Typed inputs, outputs and the caller’s authority are validated at the governed boundary before the result is used.
Every result traces back to its version.
See which capability version produced the result, for which workflow, in which case.
01 / Visual construction meets custom engineering
Extend what makes
you different.
Build visually where it’s faster.
Write code where it matters.
Either way, it runs under the same controls and lands on the same record. Your proprietary algorithms, interfaces and enterprise services stay connected to the work they support.
Code & specialized kernels
Add domain logic, parsing, validation, ranking and optimization as typed capabilities. Inspect the inputs, result and authority of each call in the business case that used it.
Your specialist logic stays connected to the case.APIs & service contracts
Reuse the pricing, risk and operations services you already trust, without rewriting them.
Explore API Client Builder →Models & provider adapters
Bring your own private or specialist models. Each is used only for the tasks and data it is approved for.
Explore model and tool routing →Connectors
Connect repositories and SaaS data without losing their permissions or where the data came from.
Explore the AI Data Plane →Reusable workflows
Build a verification or approval workflow once and reuse it across applications. Agents can invoke the same governed workflow through MCP or HTTPS.
Explore Visual Orchestration →Custom UI components
Add your own screens, charts and controls to apps, under the application’s sign-in, data scope and permissions.
Explore App Builder →An explicit capability boundaryYour code decides how.
Your code decides how.
Frozion decides whether it may.
- Contract
- Typed inputs, outputs and schemas
- Authority
- Who it acts for, for what purpose, in which tenant
- Behavior
- What it may do: read, calculate, propose, save or act
- Eligibility
- Which versions and environments may run it
- Evidence
- What it tried, what it returned, and what changed
Extend the part that makes the application yours.
Custom logic
Parsing, validation, ranking and optimization as typed capabilities.
Services and models
Enterprise APIs, private specialist models and provider adapters through defined contracts.
UI and reusable work
Custom App Builder components and reusable workflows, connected to the application’s identity, policy and evidence.
02 / One custom step, connected control
See exactly what your code did,
and what it couldn’t do.
Your receipt check joins an invoice review.
It compares quantities, reuses the calculated facts Frozion already has, and returns a typed result. ReceiptCheck is calculate-only; approval and payment remain separate, authorized steps in the workflow.
Interactive architecture example
Inspect the extension boundary
Existing invoice contextINV-1042 · revision 5
Tenant A · invoice-review purpose
Initiator ap-user42 · invoice-agent7
Reuse calculated factsFS-1042-A · 2.0% price variance
$12,240 invoice / $12,000 PO
Freshness checked for this attempt
Custom receipt logic98 received / 100 expected
Input: ReceiptInput.v1
Output: ReceiptResult.v1 · calculate only
Capability attempt
Not evaluatedReady to inspect
Choose an application definition and a condition to see how the custom step fits its contract. The example policy requires matching versions, authority, deployment and implementation evidence.
Expected by this application
Presented by the extension
What happens next
The receipt result can inform policy and human review. It cannot authorize a payment or widen the agent’s scope.
Connected implementation evidence
The same facts reach the next decision.
Agents, policies and reviewers work from the same identified inputs and accepted receipt result. Frozion checks source references and freshness again before the next governed decision uses those facts.
03 / Engineering change, with context
Know which version did what,
without a spreadsheet.
Every case keeps the capability version that ran.
Connect a capability version to the published application and execution instances that used it. Trace a result to its registered implementation, even as the surrounding technology changes.
Built by your organization
Custom capability → contract
Registered implementation · typed inputs and outputs
ReceiptCheck.v2
Managed by a provider
Approved service → route
Registered service · task and data permissions
Approved external capability
01Published applicationDeclared versions & contracts
02Execution instanceSelected capability & attempt
03Outcome evidenceResult, failure or external effect
Follow the registered capability version through the published application, its execution and the recorded outcome.
See which application versions depend on the extension.
Relate the new contract, model, mapping or code version to the application release. Running and historical executions retain the references needed to interpret their work.
Upgrade knowing exactly what it touches.Inspect the attempt in context.
See capability version, permitted inputs and outputs, authority, policy, timing, retry or failure state, and resulting evidence within the execution.
Find the cause in one place, not five.Reuse the governed process.
Reuse the same verification or approval workflow across applications, with its contracts, controls and evidence connected to each case.
Improve a shared process without rebuilding it in every app.See every workflow that uses the extension.
Inspect dependencies before replacing an implementation or contract. Compare workflow versions, validate changed behavior and keep the implementation reference connected to executions that use it.
04 / Extend the application around your stack
Keep the systems
that already do their job.
Keep the capabilities you already rely on, where they are.
Connect them to application identity, contracts, policy, state and evidence. A service credential can authenticate the downstream call while the execution retains whose business authority initiated it.
Your existing responsibilityWhat you get
IAM & service credentials
Every call retains the initiating person or workload and its delegated scope. Authority can narrow across the handoff, never widen itself.
ERP, CRM & transaction systems
Agents read and propose; writeback follows policy and any required approval. Your system of record stays authoritative.
Repositories & data platforms
Source permissions are respected, and calculated facts retain their source references.
Models & cloud-native services
Use the strengths of your connected providers, with each model approved for its tasks and data.
Provider-specific value
Use the useful differences.
Specialist models and cloud-native services can remain first-class capabilities. Govern them through explicit contracts and routes while keeping the broader business process independent of one provider’s API.
Explore Model RoutingWorkload-specific placement
Put the capability where it belongs.
Connect capabilities in your data center or your own AWS, Azure or Google Cloud account. Private models and approved provider services participate in the same governed application, using only the inputs their tasks allow.
Explore Private & Hybrid AI05 / Questions, answered
Custom technology.
Clear responsibilities.
Keep your engineering choices, with clear controls around how each capability participates in the application.
No. Existing services and systems of record can remain authoritative. Frozion connects them through explicit capability contracts, mappings and governed invocation. Custom execution capabilities are another option when specialist logic belongs directly in the execution path.
API Client Builder focuses on calling enterprise APIs through governed operation contracts. Developer Extensibility also covers custom code and kernels, models and provider adapters, connectors, reusable workflows and specialized UI components.
Yes. Bring private models, custom inference and connected provider-specific services, each approved for the tasks and data it may handle. Task contracts, versions and policy keep each capability connected to the workflow that uses it.
Every application and case keeps a record of the capability version it used, so you can see what ran. New versions do not automatically change work already in progress. Your team validates the contract and behavior before switching.
A custom component should participate in the same identity, tenant, data scope, policy and execution state as native components. Its presence in the interface is not authority to read more data or invoke a broader action. Service-side authorization and governed action boundaries still apply.
Subject to viewer permissions, runtime evidence can identify the capability and version, relevant inputs and outputs, authority context, policy decision, timing, retry or failure state and any external effect. For external providers, inspection is bounded by what their registered capability and execution interface expose.
Engineering choice. Connected control.
Build what your business needs.
Keep it part of the application.
Bring one piece of logic only your company has. We’ll show it running inside a governed workflow, with every call checked and on the record.