OSTF. View on GitHub

A PROPOSED END-TO-END WORKFLOW

From a requirement to a reviewed change.

A coding agent implements a synthetic safety-related limit. A later helper change affects the same behavior while the linked function stays unchanged. This story follows the requirement, pull requests, tests, logs and human decisions across both changes.

Follow the eight steps See the current example
FICTIONAL SCENARIO · NOT AN IEC 62304 CONFORMANCE CLAIM

KNOW THE BOUNDARY

A shared format is one part of the workflow.

The current OSTF draft exchanges local requirements, code and test links, labeled log and OpenTelemetry references, and scoped link freshness. This case also needs proposed integrations. The labels below distinguish current format data from those additions.

OSTF DRAFT TODAY

Local item IDs, code and test links, labeled log and OpenTelemetry references, trace.lock and bounded freshness states.

PROPOSED INTEGRATIONS

Jira snapshots, transitive impact analysis, baseline-bound execution evidence, approval records and release gates. None is implied by a valid stamp.

  1. 01 / INTENTEXTERNAL SOURCE PROPOSED

    Settle the requirement.

    Reviewers clarify a fictional Jira request: reject amounts above an approved synthetic limit, invalid units and unusable configuration. Jira owns the approved source. A read-only adapter would capture the exact revision and report incomplete exports. External-item design.

  2. 02 / PLANANALYSIS IS TOOL BEHAVIOR

    Map possible impact.

    An engineer checks the wrapper, shared helper, configuration and tests. OSTF links can name the requirement and relevant anchors. A dependency analyzer and reviewers decide whether the identified paths are complete.

  3. 03 / PULL REQUESTCORE LINKS TODAY

    Let the agent propose.

    The agent changes code, adds boundary tests and proposes OSTF links in the PR. A reviewer can inspect each changed location, its enclosing anchor, linked items, verifying tests and changed lock entries. Diff mapping is tool analysis; PR permissions and acceptance remain human and tool decisions.

  4. 04 / EXECUTIONEVIDENCE PROPOSED

    Bind results to the revision.

    CI runs tests on the exact candidate, including a failure and repair cycle. A future evidence reference could carry run ID, outcome, source and trace baseline, environment, and retained log digest. Current OSTF test links do not assert that a test ran. Evidence design.

  5. 05 / DECISIONHUMAN AND TOOL CONTROL

    Review, merge and retain.

    Authorized people assess implementation, test adequacy and risk, then decide whether the PR can merge. The software baseline retains its source revision, reviewed requirement and evidence. A fresh OSTF link is one input, never approval.

  6. 06 / LATER CHANGEDEPENDENCY ANALYSIS

    Catch an indirect change.

    A shared helper changes while the tracked function does not. Its OSTF stamp may remain valid. Companion analysis finds the dependency path; OSTF links identify the requirement and tests to revisit. Unknown impact remains unresolved.

  7. 07 / CORRECTIONIDENTITIES CONTINUE

    Open another PR.

    The corrective PR retains the existing requirement and link identities. A new regression test gets its own link. CI runs fresh verification, and people make a new decision. Historical results remain tied to their original baseline.

  8. 08 / RECONSTRUCTIONRETAINED EVIDENCE

    Follow the whole chain.

    A reviewer can follow the approved source, PRs, code, tests, runs, logs and decisions for one software baseline. The controlled systems must preserve access and integrity. OSTF alone does not certify safety or compliance.

TRY THE CURRENT FORMAT

Start with a runnable example.

The payment retry example has real source, tests, trace.yaml and trace.lock, plus synthetic log and OpenTelemetry references. The informative change-impact example shows the precise helper-change limit. Read the support map before claiming current tooling covers the proposed workflow.