Local-only checker
Local-only checker for logs, traces, JSON, and signed records. Nothing leaves your browser.
Logs help you debug. Proof helps another party verify.
Incident review Vendor/customer disputes Payment questions Audit evidence
Could your logs survive an incident review?
Local-only checker
Paste your input. See what is observable vs independently verifiable.
Drop in a log snippet, trace, JSON payload, signed record, or incident description. Runs entirely in your browser.
Heuristic checker. Inspects structure only. Not a cryptographic verifier. No signature verification, no issuer key lookup, no upload, no claim truth validation.
Heuristic analyzer. Inspects structure and fields only. Does not verify signatures or fetch issuer keys. How scoring works
What this does not check
It does not validate cryptographic signatures, resolve issuer keys, or verify that claimed timestamps and policy bindings are authentic.
Logs vs signed records
Same interaction. Two kinds of evidence.
An agent checks inventory via an API. Compare what internal logs capture versus what a signed record would let another party verify.
14:23:01.2
Agent invoked MCP tool: check_inventory
tool_call_id: tc_82af → pending
14:23:01.8
Tool called external API
GET /api/v2/inventory/sku_47x → 200
14:23:02.1
Policy evaluated
policy: tools.check_inventory → allow
14:23:02.4
Tool returned result to agent
trace_id: 7f3a-b2c1-9e4d
Useful for debugging. Weak for disputes.
The hard questions
What your logs cannot settle
Did the agent actually accept those terms?
Your logs recorded a policy decision. Another party has no way to verify what terms were in effect.
Did the tool call happen before or after the policy changed?
Timestamps in your system are assertions, not proof. Without a signed record, ordering is disputable.
Which party can verify this without trusting your dashboard?
Internal traces are useful for debugging. They are not evidence for a counterparty, auditor, or regulator.
Can this survive an incident review?
When three teams and two vendors are involved, screenshots and log excerpts are not enough.
What was actually authorized vs what was charged?
Payment logs show intent and outcome. They do not prove what policy applied at the moment of authorization.
Where this helps
- Incident review
- Vendor and customer disputes
- Payment and authorization questions
- Audit and compliance evidence
Methodology and source
How this checker works
Scoring rules, limits, and source code.
How scoring works
Read the exact classification rules, score ranges, and known limitations used by the analyzer.
Open methodologySource on GitHub
The analyzer logic, page source, and methodology are public so anyone can inspect what this tool does.
View sourcePrivacy boundary
Local-only diagnostic. The analyzer runs in your browser and does not upload pasted input.
Privacy policyQuestions
Frequently asked
What does this analyzer actually do?
It classifies pasted input and scores evidence-related structure such as issuer fields, timestamps, policy references, and signed-record shape. It helps separate local observability from independently verifiable evidence.
Does this page verify cryptographic signatures?
The pasted-input analyzer does not verify signatures or fetch issuer keys. It is heuristic. For cryptographic validation, use a dedicated verifier with the issuer's public key.
Does this replace auth, observability, or payment systems?
No. Signed records are additional evidence that can travel across parties. They complement auth, payment rails, observability platforms, and runtime infrastructure.
Who is this for?
Teams handling incidents, customer disputes, payment questions, or audits where another party needs independently verifiable records.
Is this tied to PEAC or Originary?
This checker is a standalone public utility. It uses PEAC concepts for signed record format in the background, but you can use the site without adopting PEAC or any commercial product. Built by Originary; source is public.
What happens to my pasted data?
Nothing leaves your browser. The analyzer runs entirely client-side. No input is uploaded, stored, or sent to any server.
Technical background
How signed records work in practice
1
Publish policy
Services expose machine-readable policy and terms so behavior can be interpreted consistently.
2
Return a signed record
After processing an agent request, the service returns a signed record of what happened.
3
Verify independently
Another party can verify the record using issuer keys and local verification tooling.
4
Use in review or disputes
Records can support incident review, dispute resolution, audit, and compliance workflows.