ERT Trace Viewer: Calibration, Verification, and Client-Readable Reporting

Public Note

This page is a public-safe research log. Some implementation details, signing configuration, provider configuration, and experimental scoring mechanics are intentionally not shown.

[REDACTED — private signing, provider, and operational configuration details]

What Was Being Developed

The Trace Viewer was developed to help people inspect ERT results more clearly.

Instead of treating an evaluation as a single hidden score, the viewer is intended to show:

• whether the report was generated successfully;
• whether the report signature can be verified;
• whether the diagnostic result appears clean, partial, or failed;
• whether evidence collection was complete;
• whether consistency remained high;
• whether a certification tier was assigned or withheld;
• and whether the report is public-safe or tied to private identity information.

The intent is to make ERT reports more accountable without forcing every reader to understand the technical internals.

What Changed

Report generation and verification

The reporting flow was restored and verified. Reports could be generated, signed, loaded back into the viewer, and checked through a verification pathway.

The viewer was refined so that it can distinguish between:

• unsigned or unverified reports;
• valid signatures;
• policy warnings;
• replay-related status;
• and actual report-integrity problems.

[REDACTED — private report-signing environment details]

Public and private sharing flow

The reporting model was separated into public and private outputs.

A public report can be shared without exposing client identity or private subject information.

A private attestation can separately bind a client or subject name to a public report when that is appropriate.

This separation matters because reliability evaluation should be shareable without automatically exposing personal, client, or proprietary information.

Report identity

Reports were updated to identify what kind of diagnostic action was performed, what scope was being tested, and what general scoring pathway was used.

This helps prevent confusion. For example, a calibration check, a provider sanity check, and a deeper reasoning-variation test should not be interpreted as the same kind of result.

Client-facing interpretation

A need was identified for a simple client-readable result section.

Instead of only showing technical values, a report should be able to communicate something closer to:

• no major failure detected;
• evidence collection was complete;
• consistency was high;
• signal strength was moderate;
• certification tier was not assigned.

This creates a better bridge between technical evaluation and real-world use.

What Was Learned

One important finding was that the most interpretable public reporting path should remain conservative.

A stable, simple client-facing path is more useful than a complex experimental path that produces confusing or misleading results.

An experimental geometry pathway showed instability in live testing and was therefore treated as not ready for public-facing claims.

[REDACTED — experimental scoring geometry and internal calibration details]

This was a useful result rather than a failure. It clarified that ERT should not overstate precision when a scoring pathway has not yet been validated.

Public-Safe Diagnostic Areas

At this stage, the viewer began supporting clearer inspection of areas such as:

• calibration checks;
• live provider sanity checks;
• multi-dimensional behavior probes;
• equivalent wording tests;
• prompt-sensitivity checks;
• ambiguity handling;
• context-drift observation;
• correction and recovery behavior;
• pressure or adversarial-framing behavior;
• and client-specific fill-in evaluation cases.

These areas are framed publicly as diagnostic categories, not as a complete disclosure of test-pack design.

[REDACTED — protected test-pack structure and private diagnostic prompts]