Fractal Computing

Fractal is MIOSA’s enterprise data partner pattern for customers whose data work is bigger than an application database: client-wide structured data, high-volume calculations, reconciliation, and customer-controlled data-plane deployments.

Use MIOSA’s built-in databases, storage, Redis, auth, volumes, and Qdrant for normal application state. Bring Fractal into the architecture when the customer needs enterprise-scale data work behind MIOSA apps, agents, sandboxes, deployments, review flows, and audit trails.

The role split

The customer should experience one product surface: their branded MIOSA app or workflow. Fractal sits behind that surface when the data problem requires it.

Enterprise data model

The first job is not to point an agent at raw tables. The first job is to map the customer’s world into a usable data model: the entities, relationships, names, identifiers, calculations, source-of-truth rules, and approval rules that the business actually runs on.

That model is the contract between the customer, Fractal, and MIOSA:

Once this model exists, MIOSA apps and agents can operate against named, reviewable business objects instead of brittle one-off queries.

How it compares to built-in primitives

Enterprise architecture

Read it left to right:

1. Customer systems remain the source of truth.
2. Fractal turns raw source data and business rules into an explicit enterprise model: ontology, taxonomy, and schema mapping.
3. Fractal runs the heavy data work against that model: high-volume calculations, reconciliation, and derived datasets.
4. MIOSA turns those outputs into a product: apps, agents, deployments, review queues, approvals, reports, and audit trails.
5. Writeback is controlled and approved. The agent should propose changes; the customer policy decides what gets promoted back.

When this is the right pattern

Use a Fractal-backed MIOSA workflow when the customer problem looks like:

• millions of invoices, claims, meters, transactions, customers, assets, or product variants;
• calculations that are simple for one row but expensive when repeated millions of times per day;
• many agent or application executions that must be compared, scored, reconciled, and audited;
• enterprise data that must stay in a customer-controlled, private, or partner-managed data plane;
• source-system writeback that must be proposed, reviewed, approved, and audited rather than performed directly by an agent.

The practical boundary is:

MIOSA built-in data services  app-local state and operational metadata
Fractal-backed data plane     client-wide structured data and heavy calculation
MIOSA app/agent layer         product workflow, approvals, audit, deployment

What the customer sees

A customer should not need to understand the internals. They should see:

• a branded app, dashboard, API, review queue, or operational workflow;
• agents and jobs that can work over enterprise data without unrestricted production write access;
• full-population calculations where sampling is not acceptable;
• proposed findings and changes with evidence;
• approvals and audit trails before anything is promoted back to source systems.

Deployment models

Engagement path

A Fractal-backed MIOSA project should start as an enterprise architecture conversation, not a blind connector install.

The usual sequence:

1. Identify the business workflow and the systems of record.
2. Define the ontology, taxonomy, and schema mapping the workflow needs.
3. Decide whether the data plane runs in MIOSA cloud, a Fractal-managed partner environment, the customer’s private network, or on-prem.
4. Define the one-way sync, freshness target, and read/propose/writeback modes.
5. Build the MIOSA app, agent workflow, review queue, reports, and audit trail around the Fractal-backed data plane.
6. Prove the workflow on real customer data before production writeback.

Contact roberto@miosa.ai to scope the MIOSA side of the engagement.

Governed writeback

Fractal-backed workflows should not let AI write directly to production systems. Use a propose-review-promote shape:

read scoped data
  -> run calculation or reconciliation
  -> produce finding/proposal with evidence
  -> route to human or policy approval
  -> promote through a controlled writeback service
  -> record audit outcome

Connector expectations

Do not assume a public connector contract from this page. A production design should be scoped with MIOSA and Fractal and should define:

• dataset and tenant identity;
• data residency and network path;
• scoped credentials or token exchange;
• read-only, propose-only, and approval-required modes;
• sync health and freshness;
• audit/event handoff;
• writeback ownership and rollback/compensation policy.

Fractal references

Public Fractal material describes the partner-side architecture in terms of digital twins, safe AI over structured data, one-way source synchronization, controlled promotion back to systems of record, locality optimization, and industry-specific deployments.

Use these as background references when scoping a MIOSA + Fractal engagement:

MIOSA’s role is the product and operating layer around that data plane: white-label apps, agents, computers, sandboxes, deployments, review, approvals, audit, reports, and customer-facing workflow.

Common enterprise workflows

Next