TENSOR Framework

Implement the TENSOR Core Candidate

Implementation candidate · 0.1.0-draft.1

Validate a portable investigation

Start with two synthetic examples and the reference validator. This establishes a reproducible baseline for the candidate binding; it does not certify an integration or prove that the recorded conclusions are true.

1. Try a case in your browser

Investigation Lab lets you inspect, import, validate, and export a candidate bundle. Use the AI-system case or the identity case. Evidence in these examples is synthetic.

2. Run the same candidate locally

Use Node.js 22 or later. The implementation candidate is on the Core review branch; the default branch retains the earlier framework until review is complete. Clone the candidate explicitly:

git clone --branch codex/core-investigation-contract --single-branch https://github.com/tensor-standards-consortium/TENSOR-Framework.git
cd TENSOR-Framework
git rev-parse HEAD
npm ci
npm run check
node core/v0.1.0-draft.1/cli.mjs core/v0.1.0-draft.1/examples/case-a.bundle.json

Record the commit returned by git rev-parse HEAD because the review branch can change. The CLI prints a validation report. Inspect its findings and declared scope; a successful reference run is not an independent interoperability demonstration. Pin the candidate artifacts when recording results.

3. Understand what travels together

  • A pinned definition carries question meaning, criteria, parameters, and transition guards.
  • The investigation record binds instances to subjects and time, attributes entries, and preserves revisions.
  • The bundle retains the exact definition bytes used by its digest pins.
  • Evidence can remain in an access-controlled repository. An evidence reference is not permission to retrieve it.

Use the candidate binding documentation and JSON Schemas. Do not substitute the legacy graph schema or reconstruct pinned definition bytes by reserializing a parsed object.

4. Choose an implementation role

The proposed roles are definition producer, record producer, reader, lossless exchanger, and transition interpreter. Implement the role your tool needs and declare its supported candidate version, profiles, required extensions, and limitations. An interpreter resolves recorded transition selections; Core does not authorize or execute tools.

Retain disagreement and unknowns. Preserve historical entries when an assessment changes. Report omissions and transformation losses before claiming a complete or lossless exchange.

5. Bring back exchange evidence

Try moving an investigation between separately developed implementations. Compare question context, evidence links, assessments, transition selections, revisions, and unsupported semantics. Publish a synthetic fixture and a scoped report through the contribution workflow.

Validation coverage and reporting · Reuse of existing standards · Extension boundaries