# OFS-Kernel 1.0.0

The OFS-Kernel reference for deterministic value computation, explicit validation, and replayable evidence within OpenForex Standards.

## Publication status
Published by the OpenForex Society, the standard-setting core of the OpenForex Foundation, as part of its established standards service to the open standards community.

## Version
1.0.0

## Last Updated
2026-09-24

## Scope and authority
OFS-Kernel 1.0.0 is presented within the Society's working OpenForex Standards framework. This page documents execution responsibilities and review criteria. Machine-readable schemas, reference executables, and conformance fixtures are separate implementation artifacts; this website does not bundle them.

## Deterministic execution
The same method version, validated input snapshot, numeric policy, and configuration should produce the same result or failure. Replay should not depend on the current clock, a fresh network quote, a local machine's number formatting, or an undocumented default.

An implementation should capture changing external information before computation and retain it as part of the input snapshot. Environment details that can change numeric outcomes belong in the execution record.

## Input contract responsibilities
| Input | Required meaning |
| --- | --- |
| Method identity | Exact TVX revision being implemented |
| Instruments and amount | Unambiguous identifiers, amount units, and permitted sign |
| Observation snapshot | Values, quote directions, timestamps, source identities, and snapshot reference |
| Numeric policy | Decimal representation, working precision, output scale, and rounding mode |
| Validation policy | Freshness limits, missing-input handling, and admissible bounds |

Names in this table describe responsibilities; they do not define finalized JSON field names.

## Validation and failures
Reject unsupported versions, unidentified instruments, incompatible units, missing required observations, and values outside the declared domain. Zero divisors, non-finite values, and precision overflow require explicit failures. Stale data should not silently become a successful live result.

Failures should identify the rule and affected input without exposing credentials. Do not return a zero amount as an error substitute: zero can be a legitimate value under a separately defined policy.

## Execution record
A successful record should identify the input snapshot, method version, unrounded intermediate values where appropriate, rounded output, warnings, and execution configuration. Retain enough evidence to reproduce the result without contacting the original oracle.

## Conformance evidence
Implementation review requires the applicable serialization, numeric policy, error vocabulary, reference fixtures, and cross-implementation results. Edge cases include very small amounts, large magnitudes, precision boundaries, inverted quotations, and invalid input combinations.

See the [TVX standard](?page=seed-content/tvx-formula/1.0.0), [audit evidence guide](?page=seed-content/audit-compliance/index), and [RFC process](?page=seed-content/rfc-proposals/index).