# OpenForex Standards

The working standards catalog of the OpenForex Society, the standard-setting core of the OpenForex Foundation.

## 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
0.2.0

## Last Updated
2026-09-24

## Current catalog
| Document | Status | Scope |
| --- | --- | --- |
| [TVX Neutrality Standard literature](?page=docs/OpenForex_Society_TVX_Neutrality_Standard_Full_Text) | Ratified working standard | Monetary neutrality and QASH architecture |
| [OFS-Kernel 1.0.0](?page=seed-content/ofs-kernel/1.0.0) | Standards reference | Deterministic execution and evidence boundaries |
| [TVX Formula 1.0.0](?page=seed-content/tvx-formula/1.0.0) | Standards reference | Valuation-method specification work |
| [Oracle system](?page=seed-content/oracle-system/index) | Standards reference | Input provenance and validation design |
| [Audit and compliance](?page=seed-content/audit-compliance/index) | Implementation guidance | Evidence and review expectations |

OpenForex Standards are ratified, established, and maintained as an operational standards service to the open standards community. Their authority derives from the OpenForex Society. The references in this catalog document the working framework and its implementation responsibilities.

## Publication lifecycle
A Draft may change substantially. Review indicates that a named revision has been submitted for structured assessment. Approved means an authorized decision record identifies the accepted text and its effective version. Deprecated material remains available for historical interpretation and should point to its replacement.

Reference articles explain the working Standard, while examples demonstrate particular relationships. Future amendments pass through the review lifecycle; that lifecycle does not place the established Standard back into draft status.

## What belongs in a specification
A complete specification states its scope, terminology, input domain, behavior, errors, invariants, security considerations, and compatibility boundaries. It identifies the tests and evidence by which a claim can be checked. Requirements should say what an implementation must do, and separate that from commentary explaining why.

## Change discipline
A correction that changes technical meaning requires review even if it looks editorial. A change to a formula, numeric policy, accepted input, or failure condition may invalidate previous results. Record the changed behavior and explain migration expectations before assigning release status.

## Making a proposal
Start with an [RFC](?page=seed-content/rfc-proposals/index), identify affected documents, and include a concrete before-and-after example. Reviewers should be able to evaluate the change without reconstructing a private discussion.

The [governance model](?page=docs/governance) describes institutional responsibilities. The [contribution workflow](?page=docs/contribution-workflow) describes how to prepare evidence and publish an accepted revision.