# Audit evidence and implementation review

A guide to assembling evidence that connects a published method, an execution, and an implementation claim.

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

## Scope
This page addresses technical traceability. It does not certify software, establish a regulatory status, or determine jurisdiction-specific compliance. Those conclusions require separately authorized reviews of an actual implementation and operating model.

## Evidence chain
A reviewer should be able to move from the specification revision to the implementation, input snapshot, numeric configuration, and output record. Identify each artifact precisely enough to retrieve or reproduce it.

| Evidence | Review question |
| --- | --- |
| Specification | Which behavior was intended, and was it draft or approved? |
| Build identity | Which source and dependency set produced the executable? |
| Input provenance | Where did observations come from and when did they apply? |
| Execution trace | Which validation and transformation steps occurred? |
| Numeric policy | Where were values rounded and residuals handled? |
| Results and failures | Can successful and rejected cases be reproduced? |
| Change history | What changed since the previous reviewed release? |

## Review process
Define scope before collecting evidence. Reproduce a successful case, then inspect invalid and boundary cases. Check outputs and errors against the documented contract. Record differences with severity, affected releases, and reproducible steps.

Checklist completion is not independent review. Publish who performed a review, what they examined, and its limitations. Avoid broad compatibility claims when only a subset was tested.

## Operational separation
A calculation review does not establish reserve ownership, custody controls, settlement finality, or redemption capacity. Those claims need evidence within a separately scoped operational assessment.

## Sensitive evidence and corrections
Use sanitized public examples. Keep credentials, private keys, personal records, and account details out of issue descriptions. Define controlled access when evidence cannot be public.

Link confirmed defects to affected artifacts and replacement evidence. Preserve the original review context rather than silently rewriting historical conclusions.

Continue with [implementation submissions](?page=seed-content/implementations/index), [kernel criteria](?page=seed-content/ofs-kernel/1.0.0), and [contribution workflow](?page=docs/contribution-workflow).