> ## Documentation Index
> Fetch the complete documentation index at: https://docs.phyi.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# SSSA Schema

> The signed attestation envelope, per-track evidence, findings, and the two signatures.

The Signed Skill and Supply chain Safety Attestation is the commodity the subnet
produces: a standardised, content-addressed, machine-verifiable document that
records a verdict, the evidence behind it, and the recommended enforcement
policy, signed and written on chain. It is one shared envelope with a
track-specific `evidence` block and a `findings` list.

## Envelope (every track)

```json theme={"system"}
{
  "track": "skills | mcp_servers | packages | repositories",
  "artifact": { "name": "", "version": "", "bundle_hash": "sha256:…", "nonce": "" },
  "verdict":  { "decision": "ALLOW | WARN | BLOCK", "risk_score": 0, "confidence": 0.0, "summary": "" },
  "evidence": { },
  "findings": [ ],
  "attestation": {
    "agent_hash": "sha256:…",
    "miner_hotkey": "",
    "validator_hotkey": "",
    "signature": "ed25519:…",
    "canonical_hash": "sha256:…"
  }
}
```

| Field                       | Type      | Meaning                                              |
| --------------------------- | --------- | ---------------------------------------------------- |
| `track`                     | enum      | One of the four tracks.                              |
| `artifact.name` / `version` | string    | Identity of the analysed artifact.                   |
| `artifact.bundle_hash`      | `sha256:` | Content hash of the analysed artifact.               |
| `artifact.nonce`            | string    | The task nonce, derived from the round seed.         |
| `verdict.decision`          | enum      | `ALLOW`, `WARN`, or `BLOCK`.                         |
| `verdict.risk_score`        | 0-100     | The agent's risk estimate.                           |
| `verdict.confidence`        | 0.0-1.0   | The agent's confidence.                              |
| `verdict.summary`           | string    | One-line human-readable rationale.                   |
| `evidence`                  | object    | Track-specific, described below.                     |
| `findings`                  | array     | The discrete issues found.                           |
| `attestation`               | object    | Agent hash, both hotkeys, signature, canonical hash. |

## Two signatures

Two signatures bind an SSSA to the parties behind it:

1. **At submission time**, the miner's hotkey signs the agent artifact, which
   binds `agent_hash` to `miner_hotkey` in the on-chain submission record.
2. **At evaluation time**, the validator that executed the run assembles the
   SSSA, the attestation body the agent produced together with the
   proof-of-execution material the validator itself generated, and signs its
   canonical hash.

Attribution to the miner flows through the pinned `agent_hash`; authenticity of
the run flows through the executing validator's signature. Because validators,
not miners, observe execution, it is the validator's signature that vouches for
the run.

## Canonical hash and verification

Let the signed content be the SSSA with the attestation block removed. The
canonicalisation applies Unicode NFC normalisation, sorts all object keys
lexicographically, and removes insignificant whitespace:

```text theme={"system"}
C(m)  = sortkeys( NFC( serialize(m) ) )
h     = SHA256( C( sssa minus attestation ) )
sig   = Sign( validator_hotkey, h )
```

Any party recomputes `h` from the published SSSA by the same canonicalisation and
checks the signature against the validator's on-chain hotkey public key. The
verifier additionally checks `agent_hash` against the round's pinned submission
record, which the miner signed at submission, to confirm which miner's agent
produced the verdict. Because the signed content includes the evidence and the
findings, and NFC normalisation removes the composed-versus-decomposed ambiguity
for non-ASCII text, the hash is stable across machines and verification succeeds
offline, independently of any server. This is the formal basis for the claim that
an SSSA is verifiable by anyone without trusting Phylax.

## The finding object

Every finding shares a common shape; the allowed `category` and `plane` values
differ by track.

```json theme={"system"}
{ "category": "", "severity": "LOW | MED | HIGH | CRIT",
  "plane": "action | context | protocol", "component": "", "title": "", "evidence_ref": "" }
```

| Track          | Allowed `category` values                                                                                                                   |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| `skills`       | `instruction_injection`, `permission_overreach`, `transitive_poisoning`, `transitive_leakage`, `context_injection`, `rug_pull`              |
| `mcp_servers`  | the skills set plus `tool_poisoning`, `manifest_tamper`, `tool_shadow`, `schema_mismatch`; `component` names which MCP component carried it |
| `packages`     | supply-chain categories, each with a phase of `install`, `import`, or `runtime`                                                             |
| `repositories` | the `vulnerabilities` list is the findings (see below)                                                                                      |

## evidence: skills

```json theme={"system"}
{
  "proof_of_execution": {
    "probe_evidence": { "file_write": "…", "dns_lookup": "…", "process_echo": "…", "canary": "…" },
    "traces": {
      "filesystem": { "hash": "sha256:…", "events": [ { "path": "…", "op": "write" } ] },
      "network":    { "hash": "sha256:…", "events": [ { "domain": "…", "proto": "dns" } ] },
      "process":    { "hash": "sha256:…", "events": [ { "cmd": "echo", "args": ["…"] } ] }
    }
  },
  "action_plane":  { "capabilities": [ { "capability": "POST_WEB", "group": "network", "protection": "dangerous", "evidence_ref": "…" } ] },
  "context_plane": { "injected_instructions": [ { "type": "instruction_injection", "excerpt": "…", "location": "…" } ] },
  "capability_manifest": ["POST_WEB", "READ_SECRET"]
}
```

The traces are recorded by the validator's instrumentation during the run;
`capability` names must come from the [canonical taxonomy](/core/scoring) and be
valid for the track.

## evidence: mcp\_servers

The dual-plane core plus an `mcp_surface` block:

```json theme={"system"}
"mcp_surface": {
  "exposed_tools": [ { "name": "", "declared_schema": {}, "observed_behavior": "", "schema_mismatch": false } ],
  "manifest_integrity": { "tampered": false },
  "tool_poisoning": [ { "tool": "", "excerpt": "" } ],
  "cross_component": [ { "path": "description -> tool_call", "note": "" } ]
}
```

## evidence: packages

```json theme={"system"}
{
  "proof_of_execution": { "…": "…" },
  "lifecycle": {
    "install_time": { "hook_executed": false, "capabilities": [] },
    "import_time":  { "side_effects": false, "capabilities": [] }
  },
  "action_plane": { "capabilities": [] },
  "supply_chain": {
    "sbom_hash": "sha256:…",
    "dependencies": [ { "name": "", "version": "", "cves": [] } ],
    "typosquat": false,
    "dependency_confusion": false
  }
}
```

## evidence: repositories

No probe and no dual plane. An `audit` block plus a `vulnerabilities` list, which
is the findings:

```json theme={"system"}
{
  "audit": { "files_analysed": 0, "lines_analysed": 0, "coverage": "" },
  "vulnerabilities": [
    { "cwe": "CWE-89", "file": "src/db.py", "line": 42,
      "severity": "HIGH", "remediation": "use parameterised queries" }
  ]
}
```