TRP 0.5.3 With Verifiable Trust Receipt Version 0.5

TRP 0.5.3 ships with Verifiable Trust Receipt (VTR) version 0.5. We list every behavior that differs from 0.5.2 under Changed and Fixed.

Added

• Verifiable Trust Receipt (VTR) version 0.5 in vtr/, with the
  specification, a JSON Schema, a Python reference library and emitter,
  independent Python and Node.js verifiers, Merkle batch signing under RFC 9162
  and 45 test vectors that both verifiers must agree on.
  • standing is an object with a result beside the band and the response.
    The result tells an incomplete evaluation apart from a failing one. A
    receipt whose required evidence is missing, or whose hard rule is
    inconclusive, carries the result incomplete with a null band and a null
    response. A triggered hard rule is a known violation, so it gives
    does_not_meet even when other evidence is missing. A critical
    condition, a value in the critical range, or a signal missing with
    on_missing: critical, sets the worst band whatever else is missing, so
    it also gives does_not_meet besides missing evidence whenever that band
    does not meet the profile. A signal with weight 0 never changes the
    standing, so its absence never gives incomplete.
  • result_digest is the digest of the evaluator output with its
    evaluation member removed. A verifier with the profile and the evidence
    re-runs either reference evaluator and compares one digest.
  • Coverage counts a requirement as checked only when its outcome is
    something other than inconclusive, so a hard rule whose field is
    present with the wrong type does not count as checked.
  • The valid vectors carry every standing result and cover every kind and
    every mode, including a hard rule field of the wrong type and a triggered
    hard rule or a critical signal beside a missing signal. The invalid
    vectors include an unknown key identifier, a missing subject, a coverage
    outside 0 to 1, an incomplete standing altered to meets and a triggered
    hard rule or a critical signal reported as incomplete.
• The TRP gate signs a VTR for every decision when given a receipt key.
• profile_from_dict in tools/evaluate.py and profileFromObject in
  tools/evaluate.js, so a parsed profile can be evaluated without a file.
  The Node.js evaluator can now be loaded as a module.
• adapters/gate/trp_gate.py, one TRP gate that judges each AI agent tool
  call before it runs and each tool result before the model sees it, with a
  decision log chained by SHA-256 and a session file shared across servers and
  frameworks.
• adapters/mcp/trp_mcp_checkpoint.py, a TRP checkpoint in front of any Model
  Context Protocol (MCP) server on stdio, with the reference profile
  adapters/mcp/profiles/mcp-tool-checkpoint.trp.json and policies for the
  official filesystem and fetch servers.
• Adapters for LangChain, LangGraph, the OpenAI Agents SDK, Google ADK, CrewAI
  and AG2 in adapters/frameworks, each checked by running the real framework
  with a scripted model.
• An evidence sample can name the profile it runs against in _profile.
  Samples without it still run against full-featured.json.
• Conformance tests for on_missing: ignore, rounding ties, a critical
  signal beside a missing signal or an inconclusive hard rule, and weight 0
  signals (48 tests, up from 42).

Changed

• Both reference evaluators honor on_missing: critical when they assign the
  band. Section 3.3 treats such an absence as a critical condition, so the
  standing is the worst band, the same as a value in the critical range. In
  0.5.2 the evaluators added a penalty that no output was used and left the band
  unchanged. tests/evidence/missing-critical-signal.json, published in
  0.5.2 with the expected standing trusted and the response full, now
  expects untrusted and suspended.
  tests/evidence/missing-ignored-signal.json covers on_missing: ignore.
• Both evaluators assign the band in a stated order of precedence. A
  triggered hard rule comes first, then a critical condition, then an
  incomplete assessment, then a warning. A value in the critical range takes
  the same precedence as a signal missing with on_missing: critical, so a
  critical condition sets the worst band whatever other evidence is missing.
  The band is the same as in 0.5.2 for every input that does not involve
  on_missing: critical or weight 0, and
  tests/evidence/critical-signal-and-missing-signal.json and
  tests/evidence/critical-signal-and-inconclusive-rule.json pin it.
• A signal with weight 0 is informational in both evaluators and never moves
  the band, including a signal whose value is in the critical range or that
  is missing with on_missing: critical. In 0.5.2 such a signal could set
  the worst band or the middle band. Section 3.3 states the rule once, where
  weight is defined. tests/profiles/valid/zero-weight-signal.json gains a
  weight 0 signal declared on_missing: critical, and
  tests/evidence/zero-weight-critical-value.json and
  tests/evidence/zero-weight-missing.json expect good against it.
• result_hash in both evaluators is the SHA-256 of the RFC 8785 canonical
  JSON form of the output without its evaluation member, so the Python and
  Node.js evaluators write the same hash byte for byte. In 0.5.2 the Python
  evaluator hashed json.dumps with sorted keys, and the Node.js evaluator
  passed the top-level keys to JSON.stringify as a filter, which dropped
  every nested member, so the two hashes differed whenever the output listed
  a signal or a rule. A result_hash recorded under 0.5.2 can differ from
  the 0.5.3 value for the same input. For an evaluation with no drift
  history, it equals a VTR result_digest in hexadecimal. The
  cross-evaluator check in continuous integration (CI) now compares
  result_hash on every profile and evidence pair.
• A non-finite number has no JSON form, so both evaluators now stop with an
  error when the output would carry one, such as a scored signal value that
  converts to not a number (NaN). In 0.5.2 both kept going and wrote the
  value as NaN or null.
• The specification header, the schema title and description, and the
  README give version 0.5.3, and the VTR library names the evaluator version
  0.5.3. The schema $id and the spec_version a profile declares stay
  0.5.

Fixed

• tools/evaluate.js rounds severity, penalty, drift moving averages, and generated sample values half to even on the exact value of each number, the way Python's round does. It used to round a tie such as 0.03125 up, and near ties such as 0.95075 could round the other way, so the two evaluators could disagree. tests/evidence/rounding-tie.json lands on both cases.

Removed

• A compiled Python file committed by mistake, with a .gitignore to keep such files out.

TRP v0.5.2

TRP v0.5.2 aligns both reference evaluators with the specification and adds the extension registry. The full list is in CHANGELOG.md.

Fixed

• Both evaluators reject a profile that uses extends, as Section 7 requires.
• A hard rule whose field is missing or has the wrong type is inconclusive in both evaluators, as Section 3.4 requires, and is listed in hard_rules_inconclusive.

Added

• The extension registry at extensions/registry.json, with x_provenance reserved for the provenance module.
• Schema support for https:// and urn: extension keys.
• Conformance tests for each change, for 42 tests in all.

Changed

• Severity is documented as 0 to 10, matching every published profile.
• The README and ROADMAP cite the concept DOI, 10.5281/zenodo.22099403, which resolves to the latest release.
• tools/README.md states that drift_detected is a placeholder that both evaluators always report as false.

TRP v0.5.1

Trust Requirements Profile v0.5.1

An open standard for stating and verifying the trust requirements of AI and
autonomous systems.

This release adds independent verification infrastructure to the v0.5
specification draft.

Added

• Conformance test suite: 27 tests covering schema validation, schema
  rejection for known violations, example profile correctness, and evaluator
  determinism.
• GitHub Actions CI running conformance and cross-evaluator checks on every
  push and pull request.
• Node.js evaluator producing standings identical to the Python reference
  implementation, with no shared code between them.
• trust.json discovery specification, defining how services publish trust
  requirements at a well-known URI following the conventions of robots.txt
  and security.txt (RFC 9116).
• INTEGRATIONS.md, describing how TRP composes with SPIFFE, AAuth, auth.md,
  MCP, W3C Verifiable Credentials, and A2A.
• Profile authoring guide.
• SECURITY.md vulnerability reporting policy.
• Evaluation metadata with result hashing for attributable, tamper-evident
  results.

Changed

• Removed trust_score from evaluator output. The standard publishes signals
  and outcome tiers; scoring stays outside the specification.

The specification version remains 0.5. Profiles targeting spec_version "0.5"
are unchanged by this release.

Released under the Apache License 2.0.

TRP Specification v0.5 Draft

Trust Requirements Profile (TRP): A Universal Trust Taxonomy for Autonomous Systems. Specification v0.5 Draft.

Trust infrastructure is the missing layer of the AI economy. TRP is the open standard that fills it: a universal trust taxonomy and machine-readable contract for declaring, verifying, and enforcing trust requirements for any entity in an autonomous system, including agents, models, workflows, and data sources.

This release includes the specification, JSON Schema, two cross-domain reference profiles (manufacturing safety, healthcare data governance), a reference evaluator, governance documentation, and contribution guidelines.

Published by Striv AI. Stewarded by the AI Trust Alliance with Ohio State University as a founding member. Contributors and domain experts welcome. See CONTRIBUTING.md.

Apache License 2.0.