Liberty One FOS ®

THE CORE™

Protected Core™ is the permanent, domain-independent mathematical authority for the canonical system result within Liberty One FOS®.

It does not collect raw information, interpret external sources or make governance decisions.

Protected Core™ receives a complete Standardized Decision Input produced through the governed upstream execution chain, applies the active canonical mathematical logic and produces the authoritative system state and Standardized System Output.

For the same admitted Core version, configuration and Standardized Decision Input, the result is deterministic and reproducible.

Domains, applications, user interfaces, integrations, Profiles and AI capabilities may evolve around Protected Core™.

They do not gain authority to redefine its mathematics, modify a completed Core result or create a competing version of canonical system truth.

HOW THE SYSTEM WORKS

Liberty One FOS® separates information preparation, mathematical execution, presentation and decision authority into different responsibilities.

Information can enter from systems, sensors, documents, databases, external providers, AI-assisted processes and domain-specific sources.

Before information can influence Protected Core™, governed capabilities may decode, validate, classify, interpret, normalize and structure it.

Where AI is enabled, AI may assist with interpretation, mapping and transaction-bound proposals.

AI does not grant admission and does not create Fusion Score, STATE or canonical system truth.

Applicable deterministic admission verifies what is permitted to progress and freezes the accepted transaction context.

Layer 2™ then produces the governed Standardized Decision Input required by Protected Core™.

Protected Core™ executes the canonical mathematical sequence and produces the Standardized System Output.

That output can subsequently be consumed through Front Layer™, applications, dashboards, integrations, machine interfaces and AI-assisted presentation.

Those downstream capabilities may present, explain, contextualize or operationalize the result within their governed responsibilities.

They do not recreate, recalculate or replace the Core mathematics that produced it.

Front Layer™ prepares the system result for decision.

Governance™ authorizes decisions where applicable.

Programs™ implement authorized decisions.

This separation allows Liberty One FOS® to support different domains, operating environments and presentations while preserving one protected mathematical authority underneath them.

Different inputs.

Different domains.

Different presentations.

One governed Core responsibility.

One canonical truth chain.

One Source of Truth.

Same Rules.

Reproducible Results.

Liberty One FOS® has been exercised across a broad and deliberately demanding assurance surface spanning Core integrity, mathematical reproducibility, regression, heterogeneous information, fail-closed behavior, cross-domain isolation, scale, semantic resolution, AI boundaries, offline execution, banking formats, customer-package execution, deployment lifecycle, protected-runtime parity and real-world-oriented scenarios.

The purpose of this testing is not simply to generate successful demonstrations.

Test surfaces are designed to challenge assumptions, expose product boundaries, verify deterministic behavior and test whether the same governed system logic remains intact when information, format, scale, execution environment, provider, host or presentation changes.

Historical failures and limitations are retained as evidence.

Where a real weakness is discovered, the intended process is:

FAIL

→ isolate the actual owner and boundary

→ remediate without changing unrelated authority

→ regression-test the change

→ revalidate the original problem

→ challenge the wider system again.

GLOBAL INDEX FUND LOOK-THROUGH

A global index-fund structure containing 2,236 underlying equities was exercised through the system.

The test materialized 8,944 sensor instances and 53,664 component instances, with 2,236/2,236 Core executions completing within the tested scale range.

Earlier testing also exposed a genuine aggregation boundary, which was subsequently remediated and revalidated.

This is important: the assurance process is intended to find real weaknesses, not merely confirm expected success.

DUPLICATE EVIDENCE INTEGRITY

Liberty One FOS® has been challenged with duplicated and provenance-related evidence conditions to test whether repeated representations of the same underlying information could improperly influence the result.

The test surface identified a real pre-Core ordering boundary, followed by focused remediation, regression, mutation testing, generated cases and repeat-determinism verification.

The principle is fundamental:

The same underlying information must not gain artificial authority merely because it appears more than once.

CROSS-DOMAIN ISOLATION

Independent domain profiles have been executed concurrently while deliberately sharing entity IDs, execution IDs, evidence IDs, provenance roots, sensor identities, component identities, source identities, timestamps and numerical observations.

Across 1,536 observations, the tested profiles remained isolated, with no cross-profile leakage or oracle mismatch in the referenced test scope.

An injected fault in one profile did not alter the result of the other.

This directly exercises the principle behind:

One Core. Many Domains.

LARGE RELATION AND CONCENTRATION GRAPHS

The system has been exercised across thousands of entities and thousands of relationships, including 3,561 equities, 14,244 sensor instances, 85,464 component instances and 6,326 tested relations.

Ranking and concentration behavior was compared against reference expectations across multiple thresholds.

This test surface examines not only whether the system can process many individual objects, but whether governed structure is preserved when those objects are connected through larger relational graphs.

EXTREME SCALE

Large-capacity testing has exercised more than 10,000 entities and millions of parameter-period cells.

One referenced scale surface included 1,202,880 parameter-period cells, 50,120 sensor instances, 300,720 component instances and 40,096 Core executions without silent truncation, missing components or Core failures in the tested run.

Later capacity work extended the surface further, including millions of additional cells and more than 160,000 Core executions.

Practical execution-time boundaries were observed before a semantic system ceiling was demonstrated.

MATHEMATICAL ASSURANCE, MUTATION AND REPRODUCIBILITY

Testing does not stop at ordinary expected-output cases.

Referenced mathematical assurance has included:

Fusion Engine regression,

mutation testing,

independent reference-oracle comparison,

deterministic serialization,

canonical identity verification,

and repeated reproducibility runs.

In one referenced Development/Test assurance closure:

129/129 Fusion Engine tests passed,

52/52 targeted mutations were killed,

and a 1,250-case reproducibility corpus remained byte-identical.

The purpose of mutation testing is specifically to challenge whether tests detect deliberately introduced mathematical defects rather than merely confirming that unchanged code still runs.

Reproducibility assurance tests the complementary requirement:

same admitted inputs,

same rules,

same active mathematical configuration,

same result.

RAW REALITY AND HETEROGENEOUS FORMATS

A 512-case Raw Reality surface produced 512/512 oracle-correct outcomes:

420 cases were correctly completed,

and 92 were correctly rejected.

The same expected completion/rejection pattern was preserved across persistent and fresh-process execution modes.

Separate heterogeneous-format testing exercised CSV, JSON, XML, XLSX, PDF and SQLite, producing 512 completed outcomes, 16 bounded outcomes and 0 unexpected outcomes within the referenced corpus.

DETERMINISTIC FORMAT BOUNDARIES

Structured-format assurance has separately exercised deterministic decoding and equivalence across multiple representations.

Referenced adapter testing includes canonical JSON, JSONL, CSV, TSV, structured logs, XLSX, SQLite and bounded PDF extraction.

Equivalent information represented through different admitted containers has been tested for convergence toward the same downstream semantic and canonical result while preserving distinct source provenance.

Negative cases have included:

XLSX formulas,

hidden sheets,

macros and active content,

undeclared ranges and structures,

SQLite access outside declared read-only boundaries,

malformed PDFs,

encrypted or active-content PDFs,

unsupported PDF structures,

and inputs that are readable but lack an admitted interpretation contract.

The intended behavior in those cases is bounded rejection, HOLD or review — not invented evidence.

SEMANTIC RESOLUTION AND PROVIDER REPLACEMENT

Liberty One FOS® has also been tested at the boundary between deterministic execution and optional semantic assistance.

Development/Test assurance has exercised provider-neutral semantic work items, replaceable simulated resolvers, resolver removal and reattachment, source-lineage verification and deterministic downstream convergence.

The tested architecture preserves an important property:

semantic resolver output is not authoritative merely because a resolver produced it.

Resolver output must return through the governed admission chain.

Provider-specific authority fields, tampered semantic work items and mismatched source lineage are designed to fail closed.

The deterministic Layer 2 path has also been exercised with the semantic resolver absent.

This tests both AI-enabled extensibility and AI independence.

MEASUREMENT DEFINITIONS AND TRANSACTION-BOUND ADMISSION

Current Development/Test work also exercises the transition from heterogeneous real-world measurements into legitimate deterministic execution.

This includes:

measurement-definition registries,

declared measurement derivation,

transaction-bound measurement contracts,

source-scoped applicability,

units,

periods,

universe,

component routing,

and admission through already governed deterministic primitives.

The objective is not to make every input reach Core.

The objective is to ensure that inputs reach Core only when the required meaning and measurement relationships can be established legitimately.

AI GOVERNANCE AND AI-ASSISTED EXECUTION

AI-related assurance is not limited to whether an AI response looks reasonable.

Test surfaces include role separation, AI admission scope, governed AI assistance, proposal-versus-authority separation, cross-surface parity and security boundaries around AI-assisted execution.

AI may assist with interpretation, mapping, orchestration and proposal generation.

Testing is designed to ensure that this assistance does not silently become:

Core authority,

Layer 2 mathematics,

transaction admission authority,

Profile authority,

or a parallel decision path.

AI OFF and resolver-absent execution are tested separately so that deterministic product capability does not depend on an external model simply because AI support exists.

PHYSICAL OFFLINE AND NETWORK ISOLATION

Physical Windows testing has included offline execution, AI-OFF operation, physical network isolation, restart/re-run behavior, online/offline parity and unchanged Protected Core behavior within the tested host/runtime scope.

In the referenced physical certification path:

physical network adapters were disconnected,

AI was OFF,

external network attempts were 0,

and the expected canonical result matched the online reference within the defined parity scope.

Separate current Development/Test deployment assurance has also exercised sealed air-gapped execution with no network or AI-provider installation.

Network-mode testing additionally distinguishes governed ONLINE operation from unrestricted internet access and verifies that OFFLINE operation does not silently create an alternate execution authority.

SCALE-OUT AND PARALLEL EXECUTION

Deterministic scale-out has been exercised across 1, 2 and 4 workers with exact result parity.

Parallelism is not permitted to manufacture system truth through voting, averaging or winner-selection between competing results.

The same canonical execution responsibility must remain intact regardless of worker count.

BANKING AND MACHINE EXECUTION

Banking-oriented test surfaces have included machine-level raw-ingress execution, ISO 20022-oriented material, line-ending and BOM transport equivalence, corporate-account baselines, synthetic scenario families and cross-format equivalence.

Formats exercised in banking-related assurance include CSV, TSV, JSON, XLSX and SQLite together with negative, ambiguous and localized representations.

One referenced banking cross-format surface completed 15/15 semantically equivalent cases with 0 hard failures and 0 semantic failures, while malformed or ambiguous negative cases remained fail-closed.

A separate 98-run frozen machine regression produced 87 expected completions and 11 expected rejections with 0 hard failures and 0 semantic failures.

Machine execution is tested as a governed product surface rather than as a second implementation of the system logic.

CUSTOMER-PACKAGE EXECUTION

Customer-facing packaging is tested separately from repository execution.

Assurance includes repository-independent materialization, package-local execution, machine-readable request/response behavior, deterministic replay, bounded backpressure, tamper detection, trust verification, entitlement verification and protected-runtime binding.

Earlier physical customer-package proof completed 6/6 within its defined scope.

The current customer-delivery assurance surface extends substantially beyond that original proof.

A dedicated protected customer-delivery conformance graph contains 20 Development/Test proof areas together with seven additional graded protection-profile proof areas.

Those proofs cover subjects including:

customer operation without the source repository,

protected-runtime behavior,

AI-OFF operation,

local entitlement,

signed trust and package verification,

dependency substitution,

host execution footprint,

secret and source-disclosure boundaries,

customer-safe support,

stateful continuity,

rollback,

profile protection,

and preservation of the selected truth-producing implementation.

These proofs remain Development/Test evidence and do not create Product, Runtime or Operational State Authority.

SIGNED PACKAGE, TRUST AND TAMPER ASSURANCE

Customer-delivery testing includes negative trust cases rather than only valid packages.

Referenced tests exercise:

unknown signers,

invalid signers,

blocked or revoked trust,

mismatched trust material,

substituted dependencies,

altered package files,

invalid entitlement,

wrong deployment identity,

and modified runtime/package bindings.

The intended result is fail-closed behavior rather than silent continuation under uncertain identity.

DEPLOYMENT LIFECYCLE AND ROLLBACK

Deployment assurance also covers what happens before and after activation.

Test surfaces include:

staging without mutating the active deployment,

failed staging with active-state preservation,

exact-target activation,

rejection of mismatched activation targets,

recovery after simulated activation failure,

known-good rollback,

stateful continuity requirements,

and preservation of operational history across rollback where the applicable continuity owner exists.

This matters because deployment correctness is not only about whether a package starts.

It is also about whether change can occur without silently losing identity, authority or recoverability.

PROTECTED-RUNTIME AND PERFORMANCE PARITY

Performance assurance is treated separately from semantic correctness.

One referenced final Development/Test performance-parity exercise compared Core, Layer 2, full Layer 2→Core execution and startup/import behavior against a frozen same-host baseline.

All four paths remained inside their predefined performance tolerances while canonical result identities remained unchanged.

The same assurance also compared the protected customer runtime against the canonical execution path and confirmed identical canonical Core result identity within the tested protected-runtime scope.

Performance observations are test evidence.

They are not production SLA commitments.

CUSTOMER-SAFE SUPPORT AND DISCLOSURE

Support-related assurance tests not only whether diagnostics can be generated, but what must not leave the customer boundary.

Customer-Safe Support Bundle testing includes protection against disclosure of:

raw customer data,

credentials,

private keys,

tokens,

source snippets,

internal paths,

stack traces,

debug dumps,

protected intermediates,

source-equivalent artifacts,

and timing metadata.

Tampering with the support bundle or attempting to expand its authority/disclosure surface is designed to fail verification.

HOST, UI AND PRESENTATION BOUNDARIES

Host and presentation testing includes Windows offline hosts, customer-facing UI surfaces, lifecycle behavior, local runtime startup, loopback behavior, Front Layer serving and presentation-boundary controls.

Presentation testing is not allowed to create a second source of truth.

UI, host, launcher and AI surfaces may expose or assist with governed product capability, but must remain outside the protected mathematical authority chain.

REGRESSION AFTER CHANGE

An important part of the assurance strategy is what happens after a localized improvement.

Generic format handling, mathematical owners, offline hosts, customer packaging and surrounding runtime components are regression-tested after targeted changes so that a local remediation does not silently redefine another already-correct owner.

One referenced structured-format assurance closure, for example, completed:

6/6 structured-format checks,

17/17 deterministic-adapter combined tests,

11/11 Local Intake foundation tests,

12/12 Windows Offline Level 2 host tests,

328/328 application tests,

together with exact mathematical assurance.

This is intentionally broader than testing only the component that was changed.

HELD-OUT, UNSEEN AND ADVERSARIAL TESTING

The current Development/Test methodology also uses historical, synthetic, unseen and held-out material.

The objective is to distinguish genuine generic improvement from implementation that has merely learned a known fixture.

Current development explicitly stresses RAW and heterogeneous information with increasingly difficult examples, including mixed structures, unknown schemas, reordered fields, nested data, multiple languages, sparse context, contradictory observations, duplicates, derived representations, malformed subsets and safe adversarial inputs.

Held-out fixtures are intended to be evaluated only after implementation work rather than being used to tune the implementation in advance.

A successful calibration is therefore not simply that the development fixture passes.

A stronger result is that unrelated historical and held-out material improves without weakening fail-closed behavior.

STANDALONE AND BATCH PARITY

Current assurance also treats standalone-versus-batch behavior as a first-class product requirement.

The same child input, with the same source bytes, admitted capabilities and rules, should preserve its interpretation and canonical result whether it is executed:

alone,

beside other files,

inside a larger folder,

beside REVIEW or REJECTED children,

or at a different position in selection order.

A problematic sibling must not silently corrupt the semantic resolution of an otherwise valid child.

PASS-ready children should be able to continue while unresolved or terminally invalid siblings remain isolated according to their own disposition.

HISTORICAL EVIDENCE IS NOT REWRITTEN

Some historical test rounds intentionally exposed product limitations, implementation defects, host constraints or assurance-harness problems.

Those findings are retained as historical evidence.

They are not retroactively rewritten as PASS simply because a later version was remediated.

The original finding and the later remediation/revalidation remain separate evidence events.

Likewise, a defect in an assurance harness is distinguished from a defect in the product rather than being silently conflated with it.

THE HIGHLIGHTED EXAMPLES ARE NOT THE COMPLETE TEST INVENTORY

Liberty One FOS® contains a much larger set of focused tests, regression suites, negative cases, mutation tests, evidence receipts, physical-runtime checks, lifecycle tests and domain-specific assurance than can reasonably be reproduced in a public FAQ.

The examples above are intended to show the breadth and testing philosophy rather than act as a complete test register.

DEVELOPMENT / TEST SCOPE

PASS always means PASS within the defined test scope.

Development/Test evidence is not presented as universal correctness, external certification, unrestricted fitness for every environment, a production SLA or a guarantee that future integrations cannot expose new boundaries.

Liberty One FOS® preserves the distinction between:

Product Authority,

Runtime Authority,

Operational State Authority,

and Development/Test Evidence.

The objective is not to prove that the system can never fail.

The objective is to make failure visible, bounded, reproducible and testable — while preserving one governed logic and one reproducible system result when the applicable contracts are satisfied.

INTEGRATION WITH EXISTING ENVIRONMENTS

Liberty One FOS® is designed to integrate with existing enterprise environments rather than require organizations to replace systems that already perform their intended functions.

Existing applications, databases, documents, sensors, providers, operational systems and domain-specific platforms can remain responsible for the capabilities they already own.

Liberty One FOS® can instead be introduced at a defined point in the information and decision chain where heterogeneous information needs to become governed, structured and reproducible decision support.

A simplified integration pattern is:

Existing systems and information sources

→ governed intake and preparation

→ deterministic admission and transaction binding

→ Layer 2™

→ Protected Core™

→ canonical system result

→ applications, integrations, APIs, dashboards, AI-assisted surfaces or downstream systems.

The surrounding systems do not need to reproduce the protected mathematical logic themselves.

They integrate through governed interfaces and contracts.

MACHINE-TO-MACHINE OPERATION

Liberty One FOS® can also operate as a headless machine-to-machine capability within an existing system chain.

Customer systems can provide governed machine input and receive structured machine-readable results, receipts and provenance without requiring a browser, dashboard or interactive user interface.

A simplified machine flow is:

Customer system

→ governed machine input

→ Liberty One FOS® customer runtime

→ admission and execution chain

→ Layer 2™

→ Protected Core™

→ machine-readable result + receipts / provenance

→ customer system.

Machine execution does not create a separate or simplified decision engine.

The transport and interaction surface are adapted for system-to-system operation while the same governed runtime responsibilities remain underneath them.

The machine boundary itself does not calculate Fusion Score, STATE or a substitute system result.

SDK, API AND INTEGRATION BOUNDARIES

Liberty One FOS® separates Product authority from the interfaces through which other systems consume or operate Product capabilities.

SDK, API, Host and Integration surfaces can expose admitted capabilities through defined contracts without inheriting authority over the underlying architecture.

A partner or customer system should therefore be able to integrate through governed interfaces without requiring access to the internal development repository or recreating Protected Core™ inside its own software.

Different consumers may use different interfaces.

The canonical execution responsibility remains one.

AI WITHIN AN INTEGRATION

AI can participate in an integrated workflow without becoming the system authority.

Where AI is enabled and admitted, it may assist with tasks such as:

understanding incoming structure,

semantic interpretation,

candidate mappings,

transaction-bound proposals,

workflow orchestration,

explanation,

and downstream presentation.

AI-generated proposals remain subject to deterministic admission before they can influence the protected execution chain.

Likewise, post-Core AI may explain or contextualize a completed result without changing what Protected Core™ actually produced.

This allows AI-assisted integrations to remain flexible without creating a second truth-producing path.

CUSTOMER-HOSTED AND PACKAGE-BASED INTEGRATION

Where appropriate, Liberty One FOS® can be delivered through a protected customer package containing the admitted runtime and integration surfaces required for the approved customer composition.

Normal customer execution does not require the development repository or internal build toolchain.

Machine, interactive and other admitted customer surfaces operate over the same governed customer runtime rather than carrying independent copies of the decision engine.

This allows the integration boundary to be adapted to the customer environment while preserving package identity, integrity, entitlement and the same protected mathematical responsibility.

INTEGRATE WITHOUT REPLACING EVERYTHING

The objective is not necessarily to replace an organization’s existing technology stack.

Liberty One FOS® can instead add a governed fusion and decision-support capability where fragmented information currently has to be reconciled across multiple systems, tools or human processes.

Existing systems may continue to:

collect information,

operate domain workflows,

store records,

control equipment,

provide specialist services,

or consume downstream results.

Liberty One FOS® can provide the governed structure between those sources and the resulting decision support.

This allows integration to focus on the point where additional structure, traceability, reproducibility and cross-source fusion are actually needed.

EVALUATION AND PILOT DEPLOYMENT

An organization should not begin with a full-scale Liberty One FOS® deployment.

A bounded evaluation or pilot is a required first step before broader production deployment.

Liberty One FOS® is domain-independent and deliberately broad in the kinds of information, environments and operational problems it can support.

The initial evaluation is therefore used to determine how the product should be composed and governed for the organization’s actual requirements and intended use.

This includes defining the appropriate Scope, information sources, governed Profiles, admitted capabilities, integrations, deployment model and, where appropriate, organization-specific Addons.

Representative customer information and existing systems should be used so that Liberty One FOS® is evaluated in the environment and context that actually matter to the organization.

The objective is not merely to demonstrate that the system can produce an output.

The objective is to establish a verified and bounded customer composition in which the relevant information, capabilities and execution paths are appropriate for the organization’s actual use case.

Depending on the agreed evaluation scope, the pilot can examine areas such as:

information intake,

heterogeneous-format handling,

semantic resolution,

deterministic admission,

normalization and structured fusion,

Layer 2™ execution,

Protected Core™ execution,

traceability and provenance,

reproducibility,

fail-closed behavior,

AI-ON and AI-OFF operation,

machine-to-machine integration,

offline or customer-hosted execution,

customer-package integrity,

customer-specific Addons where required,

Scope and Profile configuration,

and downstream presentation or integration behavior.

The evaluation should establish:

what information the organization intends Liberty One FOS® to process,

which capabilities and Addons are required,

which Scope and governed operating context apply,

which integrations and execution surfaces are appropriate,

which conditions can be handled automatically,

which conditions require clarification or additional capability,

and which boundaries must remain fail-closed.

Only after that bounded environment has been evaluated and the required customer composition has been verified should broader deployment be considered.

The pilot therefore serves two purposes:

to evaluate Liberty One FOS® against a real organizational problem,

and to establish the governed configuration in which the system should subsequently operate.

This is especially important for a domain-independent system.

The product should adapt to the organization through governed Scope, configuration, capabilities, Profiles and Addons.

The organization should not be forced into a generic one-size-fits-all operating model.

BOUNDED SCOPE FIRST

A useful evaluation should begin with a defined boundary.

For example:

one operational process,

one information flow,

one portfolio or dataset,

one machine integration,

one document family,

one decision-support problem,

or one existing system interface.

The scope can then be expanded only when the observed evidence supports doing so.

This preserves a clear distinction between:

what has been demonstrated,

what has been validated,

what remains unresolved,

and what would require additional integration or capability work.

WHY THIS APPROACH MATTERS

Large enterprise transformations create risk when too many assumptions are changed at the same time.

Liberty One FOS® is designed so that evaluation begins at a bounded integration point while preserving existing systems around it.

The organization can assess:

whether the information can be governed,

whether ambiguity is handled safely,

whether the same inputs reproduce the same result,

whether existing systems can consume the output,

whether the required Scope, Profiles, Addons and integrations have been correctly defined,

and whether the architecture provides value before a larger deployment is considered.

Start with a defined problem.

Establish the correct governed customer composition.

Integrate where the capability is needed.

Test both the expected path and the boundaries.

Verify the result before expanding the scope.

Organizations interested in evaluating Liberty One FOS® can contact TEIV AB to discuss an appropriate technical evaluation, pilot or integration scope.

DIFFERENT RESPONSIBILITY MODEL

Liberty One FOS® is not an AI model, chatbot or presentation-only dashboard.

AI systems, dashboards and applications can be highly capable at analysing, generating, interpreting, summarising and presenting information.

Those capabilities are valuable.

They are not the same responsibility as producing the canonical mathematical system result.

Liberty One FOS® separates capability from authority.

AI may assist with interpretation, semantic resolution, mapping, transaction-bound proposals, research, explanation, orchestration and operational workflows.

Dashboards and applications may present, contextualize and expose governed results.

Integrations may connect external systems, information sources and downstream consumers.

None of those capabilities becomes Protected Core™ merely because it participates in the workflow.

Protected Core™ remains the mathematical authority for the canonical system result.

Governance™ retains decision authority where applicable.

Programs™ implement authorized decisions.

Presentation does not create the result.

AI does not replace Protected Core™.

Integration does not redefine the system logic.

MORE CAPABILITY DOES NOT REQUIRE MORE AUTHORITY

A central architectural principle is that surrounding capabilities should be able to improve without silently gaining additional authority.

A more capable AI model may understand more information.

A better interface may make the system easier to operate.

A new integration may connect additional systems.

A new Addon may extend governed capability.

None of those changes should automatically redefine Layer 2™ mathematics, Protected Core™ mathematics or the canonical truth-producing chain.

This allows Liberty One FOS® to evolve around stable authority boundaries.

Better AI does not require giving AI more authority.

DOES LIBERTY ONE FOS® REQUIRE AI?

No — AI is not inherently required for canonical Layer 2™ and Protected Core™ execution.

Liberty One FOS® supports deterministic AI-OFF operation where the admitted customer composition already contains the deterministic capabilities required for the execution.

Protected Core™ does not require an external AI model to calculate Fusion Score, STATE or the canonical system result.

Layer 2™ and Protected Core™ remain deterministic owners regardless of whether AI assistance is enabled around them.

Current Development/Test assurance has exercised AI-OFF execution, including sealed and air-gapped execution paths without an installed external AI provider.

WHAT AI ADDS

AI is nevertheless an important capability layer within the wider Liberty One FOS® architecture.

Before Layer 2™ and Protected Core™, AI may help the runtime understand heterogeneous or previously unseen information.

For example, AI may assist with:

structural interpretation,

semantic resolution,

candidate mappings,

units and measurement context,

period and universe interpretation,

component routing,

missing-context detection,

transaction-bound measurement proposals,

workflow orchestration,

and reducing unnecessary customer clarification.

These are proposals and assistance.

They are not admission authority.

Where AI contributes to pre-Core preparation, applicable deterministic owners must still verify and freeze what is permitted to progress into authoritative execution.

AI AFTER CORE

AI may also operate after Protected Core™ has produced the canonical system result.

It may assist with:

explanation,

research,

contextualization,

presentation,

downstream workflows,

integration,

and operational assistance.

The canonical Core output must remain separately identifiable and unchanged.

AI may explain what the system produced.

It must not silently rewrite what the system produced.

AI-OFF DOES NOT MEAN “PRETEND AI WAS NOT NEEDED”

AI independence does not mean that every possible input must be forced through the system without AI.

Some information can already be resolved through admitted deterministic capabilities.

Other information may contain unresolved structure, semantics or context that requires additional assistance or clarification.

If an execution genuinely requires AI assistance that is unavailable, Liberty One FOS® should not fabricate the missing capability.

The correct outcome may instead be:

automatic deterministic resolution,

quarantine,

clarification required,

HOLD,

or terminal rejection,

depending on the applicable contract.

AI-OFF means that canonical deterministic operation does not contain a hidden dependency on AI.

It does not mean uncertainty is converted into invented certainty merely to complete an execution.

AI ON AND AI OFF — ONE GOVERNED SYSTEM

AI ON and AI OFF are not separate Liberty One FOS® products.

They operate around the same governed authority structure.

AI ON can provide additional adaptive assistance where admitted.

AI OFF relies on already-materialized deterministic capabilities and governed customer input.

Both must preserve the same downstream Layer 2™ and Protected Core™ owners.

AI must not create an alternate canonical-result path simply because it is enabled.

PROVIDER INDEPENDENCE

Liberty One FOS® is also designed so that AI capability is not permanently tied to one specific model or provider.

Provider independence does not mean that an arbitrary provider can be substituted without verification.

Any provider used within an admitted runtime must satisfy its applicable security, scope, provenance, capability and runtime requirements.

The provider supplies a capability.

It does not inherit system authority.

This means an AI provider can change without automatically changing the mathematical responsibility of Protected Core™.

DIFFERENT FROM A DASHBOARD

A dashboard primarily presents information.

Liberty One FOS® contains a governed execution architecture beneath its presentation surfaces.

The Platform, dashboards, ChatGPT Host, machine interfaces and other admitted presentations consume or operate product capabilities through defined boundaries.

They do not own canonical system truth simply because they display or interact with it.

The same canonical result can therefore be presented through multiple different surfaces without creating multiple sources of truth.

One Core.

Many Presentations.

WHY THIS MATTERS

Organizations increasingly want the benefits of AI without making critical system behavior inseparable from one probabilistic model, provider or cloud dependency.

Liberty One FOS® is designed to keep those concerns separate.

AI can improve interpretation, adaptation, accessibility and operational assistance.

Deterministic capabilities can continue to operate without AI where the required contracts are already satisfied.

Protected Core™ remains responsible for the canonical mathematical system result.

Governance™ remains responsible for authorized decisions where applicable.

The surrounding technology can evolve without silently redefining those responsibilities.

AI can enhance the system.

AI can help the system understand more.

AI can reduce friction.

AI can automate more of the surrounding workflow.

It does not become the authority of the system.

AI-ENABLED.

CORE-GOVERNED.

PROVIDER-INDEPENDENT.

OFFLINE-CAPABLE.

CROSS-DOMAIN ENVIRONMENTS

Liberty One FOS® is built around a domain-independent Protected Core™.

A new domain does not require a new mathematical decision engine.

Domain-specific meaning, information sources, Sensors, Profiles, Addons, reference data, applications and integrations can be composed around the same governed architecture while the protected Core responsibility remains unchanged.

This allows Liberty One FOS® to be applied across very different information and decision environments without creating a separate version of canonical system truth for each domain.

Examples of potential application environments include:

BANKING & FINANCIAL SERVICES

Customer, transaction, account, market, exposure, risk and other financial information can be brought into a governed information-fusion and decision-support structure.

Existing banking systems can remain responsible for their own operational functions while Liberty One FOS® is introduced where information from multiple sources needs to be structured, reconciled and evaluated through a governed execution chain.

ENERGY & CRITICAL INFRASTRUCTURE

Telemetry, asset condition, maintenance, operational performance, market information, environmental observations and incident information can be combined into a governed operational decision basis.

The architecture can support environments where traceability, local operation, controlled connectivity and reproducibility are important.

INDUSTRY & MANUFACTURING

Production, quality, maintenance, equipment, supply-chain and operational information can be fused to identify structural conditions, divergence, dependencies and priorities.

Existing industrial systems and control environments do not need to be replaced merely because Liberty One FOS® is introduced as an additional governed decision-support capability.

TRANSPORT & LOGISTICS

Fleet, route, traffic, maintenance, availability, supply-chain and disruption information can be structured and combined to support coordinated situational and operational decision-making.

Different source systems can continue to own their specialist functions while participating in a wider governed information structure.

INSURANCE & RISK

Customer, exposure, claims, asset, event and external-risk information can be brought together into a traceable and reproducible decision-support structure.

The exact meaning, weighting, scope and permitted use of that information remain governed by the admitted customer composition rather than being assumed by the domain label itself.

DEFENCE & SECURITY

Sensor, intelligence, logistics, asset, operational and human-reported information can be brought into traceable situational decision support.

The architecture is also relevant to environments where restricted connectivity, customer-controlled infrastructure, information provenance and offline operation are important.

The existence of a domain example does not itself constitute authorization, certification or suitability for a particular mission, regulated use or operational context.

THE DOMAIN DOES NOT DEFINE THE CORE

These examples are application environments.

They are not separate editions of Liberty One FOS®.

Protected Core™ does not need to understand banking, energy, manufacturing, logistics, insurance or defence as domain concepts.

Domain-specific information must be transformed through governed upstream responsibilities into the standardized decision input required by the protected mathematical execution chain.

This separation allows:

the domain to change,

the information sources to change,

the Sensors and Addons to change,

the customer Scope to change,

the presentation to change,

and the integrations to change,

without automatically creating a different mathematical authority.

CUSTOMER COMPOSITION IS REQUIRED

Domain independence does not mean that Liberty One FOS® should be deployed as a generic one-size-fits-all configuration.

Before broader deployment, the organization should first complete a bounded evaluation or pilot to establish the governed customer composition appropriate for its actual environment.

That process can define and verify areas such as:

Scope,

information sources,

Profiles,

Sensors,

reference data,

measurement definitions,

Addons,

integration boundaries,

deployment model,

AI requirements,

offline requirements,

and permitted execution paths.

Where an organization has stable domain-specific requirements that are not already covered by existing deterministic capabilities, customer-specific Addons or other governed capability extensions can be developed and admitted without creating a new Protected Core™.

The product adapts around the Core.

The Core does not become domain-specific.

ONE CORE. MANY DOMAINS. MANY PRESENTATIONS.

Different organizations may therefore use Liberty One FOS® for very different purposes.

What changes is the governed composition around the protected mathematical authority.

What does not change merely because the domain changes is the responsibility of Protected Core™ for the canonical mathematical system result.

CAN LIBERTY ONE FOS® OPERATE OFFLINE?

Yes.

Offline capability is a first-class architectural principle of Liberty One FOS®.

The system is designed so that canonical deterministic execution does not inherently require continuous internet connectivity, an external cloud service or an external AI provider.

PHYSICALLY OFFLINE EXECUTION

Development/Test assurance has exercised Liberty One FOS® in a physically disconnected Windows environment with physical network adapters disconnected and AI disabled.

Within that tested host/runtime scope:

external network attempts were recorded as zero,

the governed execution path remained available,

Protected Core™ responsibility was preserved,

the expected canonical result matched the referenced online result,

and execution was repeated successfully after restart.

This demonstrates that the tested canonical execution path did not depend on continuous external connectivity or an AI provider.

SEALED AND AIR-GAPPED EXECUTION

Separate current Development/Test assurance has also exercised sealed, air-gapped customer execution with AI OFF.

Within that defined test scope, the admitted FUSION_SERVICE composition completed without external network access or AI-provider installation.

The customer-delivery architecture also supports local verification of package identity, trust, entitlement and protected runtime material without transferring canonical execution authority to an external service.

AI-OFF OPERATION

Offline and AI-OFF are related but separate operating conditions.

AI-OFF means that the execution uses the deterministic capabilities already admitted and materialized for that customer composition without requiring an AI provider.

Where those deterministic capabilities are sufficient, Layer 2™ and Protected Core™ can execute through the same governed downstream owners.

If a particular input genuinely requires semantic assistance or another capability that is not available offline, Liberty One FOS® must not fabricate the missing capability merely to complete the run.

The correct result may instead be clarification, quarantine, HOLD, rejection or another explicit fail-closed disposition according to the applicable contract.

OFFLINE DOES NOT MEAN UNGOVERNED

Removing external connectivity does not remove the system’s integrity requirements.

An offline deployment must still preserve the applicable:

product and package identity,

runtime integrity,

entitlement,

Profile and Scope,

admitted capabilities,

execution contracts,

provenance,

and validation requirements.

Offline operation is not a bypass around admission, security or governance.

It is another governed operating environment.

CONNECTED AND OFFLINE ARE NOT DIFFERENT TRUTH SYSTEMS

Network availability is an operating condition.

It is not mathematical authority.

Being online does not grant an integration, cloud service or AI provider additional authority over the canonical result.

Being offline does not create a different Protected Core™.

An admitted connected environment may use governed external services and providers.

An admitted offline environment may rely entirely on locally available deterministic capability.

Both must preserve the same authority boundaries.

PLATFORM AND HOST SUPPORT REMAINS VERIFIED-SCOPE SPECIFIC

Liberty One FOS® is designed for multiple Runtime, Host, machine and presentation environments.

Current customer architecture includes governed customer-hosted execution, Windows interactive and hard-offline surfaces, machine/headless operation and Linux machine/headless startup where included in the admitted package.

That architectural portability must not be confused with blanket certification.

A verified Windows physical-offline result does not automatically prove every operating system, processor, host, deployment model or customer composition.

Additional environments are claimed only within the scope in which they have actually been implemented and verified.

WHY THIS MATTERS

Organizations operate under very different technical, regulatory and security constraints.

Some environments are continuously connected.

Some permit external AI.

Some require customer-hosted infrastructure.

Some restrict external network access.

Some may need periods of complete physical isolation.

Liberty One FOS® is designed so that these differences can be handled through governed Runtime composition rather than by creating a different mathematical decision engine for every environment.

Different environments.

Different domains.

Different capabilities.

Different presentations.

One governed Core responsibility.

One canonical truth chain.

One Core.

Many Domains.

Many Presentations.

One Source of Truth.

Same Rules.

Reproducible Results.