Methodology
How the evidence analyzer works, what it checks, how scoring works, and what it does not do.
Record surfaces
The analyzer offers a realistic sample for each major PEAC record surface, and for each shows what is observable, what is independently verifiable, what is missing, and the ideal signed-record shape: API call, MCP tool run, agent action, gateway decision, payment event, and provisioning event. Example record-type strings shown in results are illustrative; confirm them against the current PEAC schema before production use.
How classification works
The analyzer classifies your input into one of five categories based on structural detection:
Signed record
Detected when input contains three base64url-encoded segments separated by dots (compact JWS format). The analyzer decodes the header and payload to check for specific evidence fields.
Structured JSON
Detected when input parses as valid JSON. The analyzer inspects the object for evidence-relevant fields like issuer, timestamps, policy references, and identifiers.
Log lines
Detected when input contains timestamp patterns ([HH:MM:SS], ISO 8601 dates), log level indicators, or status codes.
Trace or request
Detected when input contains HTTP methods (GET, POST, etc.), trace IDs, request IDs, or HTTP version strings.
Plain text
Default classification when no structured pattern is detected. The analyzer counts evidence-related keywords to estimate relevance.
How scoring works
Scores are heuristic estimates based on detectable properties in the input. They reflect what evidence characteristics are present, not a formal security audit or compliance assessment.
Signed record scoring
| Property detected | Points |
|---|---|
| Base score (signed record present) | +40 |
iss (issuer) in payload | +10 |
occurred_at or iat (timestamp) | +10 |
policy or policy.uri | +10 |
type or kind | +10 |
ext (extensions present) | +8 |
kid in header | +7 |
typ in header | +5 |
JSON scoring
| Property detected | Points |
|---|---|
| Base score (structured data) | +15 |
Issuer field (iss, issuer) | +8 |
| Timestamp field | +8 |
| Policy or terms reference | +6 |
| Type, kind, or action field | +6 |
| Status or result field | +5 |
| Identifiers (ID, request_id, trace_id) | +4 |
| Nested structure (depth > 1) | +3 |
Log and trace scoring
Logs score 5 to 25 based on the number of distinct evidence property types found (timestamps, status codes, identifiers, policy references, URLs, agent references) plus a line-count bonus. Traces score 10 to 35 using similar property detection for HTTP methods, status codes, headers, and timing data.
Plain text scoring
Scores 3 to 12 based on the count of evidence-related keywords found (such as "agent," "tool," "api," "payment," "authorized," "policy," "denied").
What the analyzer checks
- Structural format of the input (JWS, JSON, timestamped lines, HTTP patterns, or unstructured text)
- Presence of evidence-relevant fields: issuer identity, timestamps, policy references, type/kind classification, extensions, key identifiers
- For signed records: actual base64url decoding of header and payload segments to inspect real field content
- For JSON: recursive field inspection for known evidence property names
- Distinct evidence property types in logs and traces
Signature verification (signed records)
When you paste a signed record (a compact JWS), the page verifies its Ed25519 signature in your browser using native WebCrypto. It enforces alg: EdDSA (rejecting none, HS*, and RS*), verifies the exact base64url(header) + "." + base64url(payload) signing input without re-serializing the JSON, and reports one of four states: VALID, INVALID, UNABLE_TO_RESOLVE_KEY, or UNSUPPORTED_ALG. The verification key comes from a JWK/JWKS you paste, or from an issuer key you explicitly choose to resolve (the exact URL is shown before any request is made). A valid signature proves who issued the record and that it was not altered. It does not assert that the claims inside are true.
What the analyzer does not check
- The structural scorecard (logs, traces, JSON) is heuristic and does not verify signatures
- It does not validate that claimed timestamps are accurate
- It does not confirm policy binding against a live policy
- It does not contact any external service unless you explicitly trigger an issuer-key lookup (the URL is shown first)
- It does not assess the trustworthiness of the issuer, and a valid signature does not make the claims true
- It is not a substitute for a formal security audit, compliance review, or legal assessment
Known limitations
- Classification is heuristic. Some inputs may be miscategorized if they match multiple patterns.
- Scores within a category vary based on detected properties, but they are estimates, not formal measurements.
- The analyzer cannot distinguish between well-formed but fabricated data and authentic records.
- Your pasted input is never transmitted. Analysis and signature verification happen in your browser using JavaScript. The only network request the page can make is an issuer-key lookup you explicitly trigger, with the URL shown first.
Source
The analyzer logic is visible in the page source. The underlying standard is PEAC Protocol (Apache-2.0). Source code is on GitHub.