Methodology
How the evidence analyzer works, what it checks, how scoring works, and what it does not do.
How classification works
The analyzer classifies your input into one of five categories based on structural detection:
Signed receipt
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 receipt scoring
| Property detected | Points |
|---|---|
| Base score (signed artifact 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 receipts: 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
What the analyzer does not check
- It does not verify cryptographic signatures
- It does not resolve issuer public keys or JWKS endpoints
- 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 (all analysis is client-side)
- It does not assess the trustworthiness of the issuer
- 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 artifacts.
- No data is transmitted. All analysis happens in your browser using JavaScript.
Source
The analyzer logic is visible in the page source. The underlying standard is PEAC Protocol (Apache-2.0). Source code is on GitHub.