Independent verification tool for Scarp governance evidence packs.
Licensing notice. Source code in this repository is licensed under Apache-2.0 (see LICENSE). All documentation, including this README, CANONICALIZATION.md, PATENTS.md, and all other non-code files, is © 2026 Victor Davidenko. All rights reserved. No license is granted to copy, redistribute, modify, or create derivative works from the documentation. The ideas, architectural descriptions, analysis, and governance framework described in the documentation are the subject of pending patent application USPTO 64/044,851. See PATENTS.md.
Scarp is a four-layer substrate protocol for governable AI. Each layer addresses a distinct requirement that arises when AI agents operate across organizational boundaries, interact with sensitive data, and make decisions that carry legal and regulatory consequences:
- Layer 1, Identity. How entities (agents, systems, tools, providers) prove who they are, who they act on behalf of, and what they are authorized to do. Cross-organizational identity verification lives here.
- Layer 2, Cooperation. How governance instances in different organizations establish mutual trust, accept each other's attestations, and bridge evidence chains across organizational boundaries.
- Layer 3, Governance. How every action an AI agent takes is evaluated against policies, allowed or blocked, and recorded as cryptographically signed evidence that any party can verify independently. Scarp Governance Gateway implements this layer.
- Layer 4, Settlement. How governance contracts define enforceable delegation scope, liability attribution, dispute resolution, and governed value settlement between cooperating entities.
This repository focuses on Layer 3. The evidence corpus and verification tool demonstrate what the Governance layer produces. The multi-agent coordination section later in this document maps unsolved cross-agent governance problems to the other three layers, showing where standardization work is required before those problems can be addressed responsibly.
Scarp Governance Gateway is a production implementation of the Governance layer. It operates as a policy enforcement point between AI agents and the services they consume (LLM providers, MCP tool servers, and other agents). Every governed interaction produces a signed evidence pack: a structured, timestamped record of the request, the classification result, the policy evaluation, the decision, and the control state at the moment the decision was made.
This repository contains scarp-verify, a standalone command-line tool that verifies the integrity and authenticity of those evidence packs without any dependency on Scarp Gateway itself. It also contains a reference corpus of 17 evidence packs covering the gateway's full governance surface.
Governance evidence has value only if it can be verified by a party that did not produce it. If verifying an evidence pack requires the governance system's cooperation, the evidence reduces to self-attestation. A regulated organization presenting governance records to an auditor, a regulator, or a court needs those records to stand on their own.
Scarp Gateway's evidence architecture is designed around this constraint:
- Signing keys live in the customer's own key management infrastructure (cloud KMS, hardware security module, or any system that supports RS256 signing). The gateway requests signatures through a key management interface but never holds or accesses the private key material.
- Evidence packs are written to the customer's own storage. The gateway keeps no copy and transmits no telemetry.
- The pack schema, the canonicalization algorithm, and this verification tool are all public. Any party with access to the pack file and the corresponding public key can verify the signature and reconstruct the canonical hash independently.
- Within a workflow, each pack carries the SHA-256 hash of the prior pack's signature (
prior_pack_hash), forming a cryptographic chain. A withheld or reordered pack breaks the chain. This means a governed party cannot selectively suppress evidence from a workflow's record.
The gateway is a third-party governance tool running in the customer's infrastructure. It has no commercial relationship with the AI providers or agent developers whose interactions it governs. Every link in the evidence chain (the signing key, the storage, the verification tool) is independent of the gateway's own infrastructure.
The evidence corpus in this repository covers the gateway's full governance surface. This section describes what that surface includes, because the packs are only meaningful in the context of the controls they record.
Content classification and data loss prevention. Every governed interaction passes through a classification pipeline that inspects content for sensitive material: PII, credentials, financial data, secrets (API keys, private keys, connection strings), and adversarial prompt patterns. Classification runs in both directions on every governed surface. On the provider route, both the request to the LLM and the LLM's response are classified. On the MCP tool route, both the tool call arguments and the tool's response are classified. Policy rules fire at configurable thresholds, producing BLOCK or REDACT decisions with recorded reason codes. The classification pipeline version is stamped on every pack.
Kill switches. Five hierarchical scopes allow an operator to halt governed AI interactions at any granularity: global (all traffic), provider (a specific AI provider), model (a specific model), agent (a specific agent), or tool (a specific MCP tool). Kill switch state is checked before any other processing. When a kill switch is active, the request is blocked immediately; no classification runs, no provider or tool call is made. The state of all five scopes is recorded on every evidence pack regardless of whether a kill switch was the reason for the decision.
Access control and entity lifecycle. Every entity (provider, model, agent, tool, system identity) must be explicitly registered before the gateway will permit any interaction. Unregistered entities are blocked at the identity layer, even if they present valid authentication credentials. Tools carry an allowed_callers list; agents carry an allowed_tool_ids list. Both sides must independently authorize each interaction. Tools have lifecycle states (ACTIVE, SUSPENDED, PENDING_APPROVAL, MAINTENANCE, DECOMMISSIONED) enforced independently of kill switches and policies.
Workflow tracking and chain integrity. The gateway assigns a workflow_id at the start of each governed workflow and tracks actions across multiple hops through continuation tokens. Each evidence pack carries a workflow_action_index (its position in the workflow sequence) and a prior_pack_hash (the SHA-256 of the preceding pack's signature). This forms a hash chain: the complete sequence of governance decisions within a workflow is independently reconstructable, and a missing or reordered pack is detectable.
System-to-agent governance. Non-agent callers (scheduled jobs, automation pipelines, batch processes) are governed through a separate system registry with the same classification and policy pipeline. The actor_type field distinguishes human-initiated, agent-initiated, and system-initiated interactions.
The samples/corpus/ directory contains 17 signed evidence packs produced by a live Scarp Gateway instance (pipeline version 0.1.58). These are production-format packs generated through the gateway's standard governance pipeline, covering every governance capability described above. No pack was hand-constructed or synthesized; every field in every pack was computed by running gateway code.
The packs are organized below by the governance capability they demonstrate.
Pack 01 (pack-01-provider-allow.json). A registered agent sends a clean request to a registered LLM provider. The gateway classifies both the request and the response, evaluates policy (no rule matches), records kill switch state (all five scopes inactive), and allows the interaction. This is the baseline bilateral evidence pack: both directions governed, both directions clean, full pipeline execution recorded.
Pack 08 (pack-08-mcp-allow.json). A registered agent sends a clean MCP tool call to a registered, active tool. The gateway verifies the agent is in the tool's allowed_callers list, classifies the tool call arguments and the tool response, evaluates execution policy, and allows the interaction. Same governance pipeline as the provider route, applied to the MCP tool boundary.
Pack 02 (pack-02-request-block.json). An agent sends a request containing an RSA private key header in the message body. The request classifier detects the secret material (category SECRETS, detection code SEC-004). The policy rule fires at the BLOCKED threshold and the gateway blocks the request before it reaches the LLM provider. The provider never sees the content.
Pack 03 (pack-03-response-block.json). An agent sends a clean request asking the LLM to generate example key material. The request passes classification. The gateway proxies to the provider, receives a response containing PEM key material, and the response classifier detects it. The response policy fires and the gateway blocks the response. The bilateral pack records both the clean request classification and the blocked response classification.
Why response-direction governance exists. Without it, you control inputs and have zero visibility over what comes back. The response is where the data actually moves. Three scenarios make the case:
- An LLM generates a real-looking PEM key block in its response. If the agent uses it downstream in a tool call or configuration write, that is an unmanaged credential. The gateway catches PEM material in the response before the agent can act on it. (Pack 03 demonstrates this scenario.)
- An adversary embeds instructions in a document that reaches the LLM through retrieval-augmented generation. The LLM echoes back sensitive data from its context: system prompts containing API keys, customer records from the retrieval step. The request looked clean. The danger is entirely in the response.
- An agent asked for a summary. The LLM returned full unredacted records instead. GDPR data minimization and SOC 2 access controls require governing what data flows to the agent, not only what flows out.
Pack 09 (pack-09-exec-block.json). An agent sends an MCP tool call with an API key (sk-live-...) in the tool arguments. The execution-direction classifier detects the secret (category SECRETS:api_key). The execution policy fires and the gateway blocks the tool call. The tool endpoint never receives the request.
Pack 10 (pack-10-mcp-response-block.json). An agent calls an MCP tool (employee_lookup) that returns employee records containing PII (SSNs, email addresses, phone numbers). The agent was not authorized to receive that PII level. The tool is the data source here; no "the customer sent it" argument applies. The response classifier detects the PII across multiple categories, the response policy fires, and the gateway blocks the response before it reaches the agent. This is pure exfiltration prevention.
These five packs demonstrate each scope in the five-level kill switch hierarchy. In every case, the kill switch check runs first (before classification, before policy evaluation, before any provider or tool call), and the evidence pack records which scope was active.
Pack 04 (pack-04-ks-global.json). Global scope active. All governed AI interactions blocked organization-wide.
Pack 05 (pack-05-ks-provider.json). Provider scope active for a specific provider. Traffic to that provider blocked; other providers unaffected.
Pack 06 (pack-06-ks-model.json). Model scope active for a specific model. Traffic to that model blocked; the provider and other models unaffected.
Pack 07 (pack-07-ks-agent.json). Agent scope active for a specific agent. That agent's access to all governed services blocked; other agents unaffected.
Pack 11 (pack-11-ks-tool.json). Tool scope active for a specific MCP tool. Access to that tool blocked; other tools unaffected.
Pack 12 (pack-12-tool-suspended.json). An operator sets a tool's status to SUSPENDED. An agent attempts to call the tool. The gateway's lifecycle check blocks the request at pre-validation. This is a lifecycle enforcement action, distinct from both kill switches and policy blocks.
Pack 13 (pack-13-caller-not-authorized.json). An agent attempts to call an MCP tool whose allowed_callers list does not include that agent. The gateway's bilateral access control check fails and the request is blocked. Neither valid authentication nor agent registration is sufficient; the specific agent-tool pairing must be authorized on both sides.
Pack 15 (pack-15-entity-not-registered.json). A caller authenticates with valid credentials but is not registered in either the agent registry or the system registry. The gateway blocks the request at the identity layer. The actor_type field records "unregistered," distinguishing this from a system failure. Valid credentials alone are insufficient; every entity must be explicitly registered.
Pack 14 (pack-14-s2a-allow.json). A registered system entity (a batch scheduler, actor_type: system) sends an MCP tool call. The gateway resolves the caller through the system registry, verifies authorization, classifies content, evaluates policy, and allows the call. System-initiated interactions receive the same governance treatment as agent-initiated interactions.
Pack 17 (pack-17-mcp-continuation.json). A registered agent sends an MCP tool call as the first action in a new workflow. The gateway generates a workflow_id, sets workflow_action_index to 0, evaluates governance, allows the call, and issues a continuation token to the agent. The continuation token carries encrypted workflow state (workflow_id, chain depth, sensitivity ceiling, call chain). This pack is the chain root: prior_pack_hash is null.
Pack 18 (pack-18-provider-continuation.json). The same agent presents the continuation token on a subsequent provider call. The gateway validates the token, verifies the agent matches the token's target, increments workflow_action_index to 1, evaluates governance, and stamps prior_pack_hash with SHA-256 of Pack 17's pack_signature. This cryptographically chains Pack 18 to Pack 17. Anyone with both packs can verify that Pack 18 follows Pack 17, that no intermediate pack was withheld, and that the workflow_id and action sequence are consistent.
V1 supports multi-agent workflows through tool-mediated coordination. Agents do not communicate directly. All data exchange occurs through governed MCP tool calls, and a system entity (conventional orchestration infrastructure, not an autonomous AI agent) manages workflow choreography through the gateway's S2A governance surface. A typical multi-agent workflow looks like this:
- System entity triggers Agent A through the gateway. Governed. Evidence pack produced.
- Agent A performs research via governed MCP tool calls. Governed. Evidence packs produced.
- Agent A writes results to any downstream tool (storage, CRM, database, messaging system, or any other MCP-governed endpoint). Governed. Evidence pack produced.
- System entity polls for completion via governed MCP call. Governed. Evidence pack produced.
- System entity triggers Agent B through the gateway. Governed. Evidence pack produced.
- Agent B reads from the output tool via governed MCP tool call. Governed. Evidence pack produced.
- Agent B continues work via governed provider and MCP calls. Governed. Evidence packs produced.
Every boundary crossing produces a signed evidence pack. No ungoverned data channel exists between any entities. The system entity is authenticated and governed through the same S2A surface demonstrated by Pack 14 in this corpus. The tool-mediated pattern composes from the same primitives demonstrated by the other 16 packs: content classification, kill switches, access control, entity lifecycle, and workflow chain integrity.
Direct agent-to-agent delegation (Agent A issuing a "delegate to Agent B" instruction through the gateway, with the continuation token reissued to target Agent B) is technically feasible. The code change would be narrow. The gateway could modify continuation token issuance to set the target field to a different agent's entity_id based on a delegation header.
This is deliberately not shipped. The reason is that governed A2A delegation requires answers to eight open questions, and no framework, standard, or specification has answered any of them. Scarp's four layers are interlocking; every question below ultimately requires all four to function together. The per-question layer attribution identifies where the specific unsolved primitive sits, the place where no standard or protocol exists today. Layer 3 (Governance) never appears in these attributions because it is the one layer that is shipped.
Q1: Cross-agent liability attribution (Layer 4, Settlement). When Agent A delegates to Agent B and Agent B generates harmful content, who bears liability? This question applies whether the two agents belong to different operators or to the same organization. Even within a single company, delegation creates an accountability gap: which team authorized the delegated action, which budget absorbs the consequence, and which agent's governance record is the one a regulator examines. Across organizations, the question compounds: the delegator's operator? The executor's operator? Both? In what proportion? The gateway can record that delegation occurred. The evidence pack would show it. But the governance meaning of that record (who is accountable for the delegated action) has no legal or contractual framework. Shipping delegation without a liability model means customers bear unquantified risk.
Q2: Cross-organizational trust verification (Layers 1 and 2, Identity and Cooperation). When Agent A and Agent B belong to different organizations (different gateway instances, different identity tenants, different cloud providers), who vouches for Agent B's identity and governance posture? V1's Identity layer handles single-organization entity registration. Cross-org delegation requires mutual trust verification: "I trust that your governance instance governs Agent B to a standard I accept." No protocol exists for this exchange.
Q3: Delegation scope boundaries (Layers 2 and 4, Cooperation and Settlement). When Agent A delegates to Agent B, what permissions does B receive? Agent A's full scope? A restricted subset? Who defines the restriction? The sensitivity ceiling mechanism prevents escalation within a single agent's workflow. Cross-agent scope partitioning requires governance contracts between entities that define enforceable boundaries on delegated work, and a negotiation protocol between governance instances to establish those boundaries. No standard defines either.
Q4: Cross-agent revocation propagation (Layers 1 and 2, Identity and Cooperation). If Agent A's kill switch fires after Agent A has already delegated to Agent B, does Agent B's work stop? Kill switch checks run against the presenting agent's chain within a single continuation token. Tool-mediated workflows with separate tokens per agent do not share a token chain. Proper cross-agent revocation requires a propagation mechanism so that revoking Agent A's authority cascades to any agents working on Agent A's behalf.
Q5: Auditability of intent (Layer 4, Settlement). In tool-mediated coordination, evidence packs prove that Agent A wrote data and Agent B read data. They do not prove Agent A intended Agent B to act on that data. More critically, they do not prove what scope or constraints Agent A intended to impose on Agent B's use of it. Intent attribution across agent boundaries is a governance primitive that requires explicit delegation declarations. No standard defines how AI agents declare delegation intent in a machine-verifiable way.
Q6: Sensitivity ceiling inheritance across delegation boundaries (Layers 2 and 4, Cooperation and Settlement). Agent A's workflow has a sensitivity ceiling of CONFIDENTIAL. Agent A delegates to Agent B, whose own governance permits SECRET. Does the delegated work inherit Agent A's lower ceiling (secure, but restricts Agent B's capabilities) or run under Agent B's higher ceiling (permissive, but potentially violates the constraints under which Agent A's operator authorized the original workflow)? Cross-agent delegation requires a ceiling negotiation protocol: who sets the floor, who can raise it, and what evidence proves the agreed ceiling was enforced throughout the delegated work.
Q7: Evidence chain continuity across governance instances (Layer 2, Cooperation). Packs 17 and 18 prove chain integrity through prior_pack_hash within a single governance instance. When Agent A is governed by Instance 1 and Agent B by Instance 2, the hash chain breaks at the delegation boundary. Instance 2 cannot verify the chain root because it has no access to Instance 1's evidence store. A regulator or auditor reviewing the complete workflow receives two disconnected chain fragments with no cryptographic link between them. Cross-instance evidence chain bridging requires a shared anchoring protocol so that Instance 2's first pack can reference Instance 1's last pack in a verifiable way.
Q8: Governance policy reconciliation (Layers 2 and 4, Cooperation and Settlement). Agent A's governance instance classifies "financial data" at a BLOCKED threshold. Agent B's instance classifies the same content category at REDACTED (meaning it passes through with masking). When A delegates to B, which policy governs? If B's policy applies, the delegation effectively downgrades governance without the consent of Agent A's operator. If A's policy applies, B's instance must accept and enforce a foreign policy it did not author. Policy reconciliation across governance instances requires a common policy schema, a conflict resolution protocol, and evidence that the resolved policy was actually enforced on the delegated work.
These design constraints impose real costs on multi-agent workflows:
Latency. Every agent-to-agent handoff requires a write, a poll, a trigger, and a read. This adds seconds to minutes per handoff depending on polling frequency. Direct delegation would eliminate the intermediate storage round-trip.
Governance overhead. Polling generates evidence packs on empty reads. Each poll is a governed MCP call that produces a signed pack recording that nothing happened. These are valid governance records but they inflate the evidence store with low-value entries.
Schema rigidity. Agent context must be serialized into a tool's schema (JSON in a storage blob, CRM record fields). Nuance that would survive direct delegation is lost when flattened into a tool's input format.
No parallel fan-out. When Agent A needs three analyses performed simultaneously by Agents B, C, and D, the system entity triggers each sequentially. Concurrent multi-agent work is blocked entirely in V1.
No real-time collaborative reasoning. Two agents iteratively refining a shared analysis requires multiple tool write/read cycles with system polling between each round. Interactive multi-agent reasoning is reduced to batch-sequential exchange.
These costs are the price of responsible design in the absence of governance standards. No existing framework, protocol, or product answers the eight questions listed above. The questions are not engineering problems that better tooling can solve in isolation. They are standardization problems: cross-agent liability attribution, cross-organizational trust verification, delegation scope contracts, revocation propagation, intent auditability, sensitivity ceiling negotiation, evidence chain bridging, and policy reconciliation each require industry agreement on governance primitives that do not yet exist. We chose not to ship A2A delegation without those answers, fully aware that the latency, overhead, and capability constraints described above are the cost of that decision. The alternative is shipping the plumbing and leaving customers to discover in production that nobody defined who is liable when a delegated agent causes harm, how revocation propagates across a delegation chain, or what happens when two governance instances enforce conflicting policies on the same workflow.
Each of the eight questions maps to a Scarp protocol layer. Layer 3 (Governance) is shipped; it is the gateway itself and this evidence corpus. The remaining layers address the unsolved problems:
| Scarp layer | Standardizes | Unlocks |
|---|---|---|
| Layer 1: Identity | Standardized entity registration, verification, and revocation propagation | Every identity implementation built today without a standard is a retooling liability when one forms. Standardized identity primitives solve intra-org governance (consistent entity types, revocation, authorization scope) and cross-org governance (agents from different organizations participating in shared workflows) simultaneously |
| Layer 2: Cooperation | Mutual trust verification between governance instances, cross-instance evidence bridging, ceiling negotiation | Gateway instances in different tenants can accept each other's governance attestations, evidence chains can bridge across instances, sensitivity ceilings can be negotiated across delegation boundaries |
| Layer 3: Governance | Per-action governance evaluation with signed evidence | Shipped (Scarp Gateway V1) |
| Layer 4: Settlement | Governance contracts with enforceable delegation scope, governed economic transactions | Liability attribution, delegation scope boundaries, sensitivity ceiling inheritance, intent auditability, policy reconciliation, and governed value settlement between cooperating entities |
The gap between "ungoverned and fast" and "governed and serial" closes when these layers are standardized. The eight questions are solvable. The solutions require cross-organizational agreement on identity verification, trust exchange, and governance contracts. That is standards work. It is the work Scarp is designed to frame.
| Pack | File | Decision | Reason | Governance surface |
|---|---|---|---|---|
| 01 | pack-01-provider-allow.json | ALLOW | NO_MATCH | Provider, bilateral classification |
| 02 | pack-02-request-block.json | BLOCK | REQUEST_POLICY_BLOCK | Provider, request DLP (secrets) |
| 03 | pack-03-response-block.json | BLOCK | RESPONSE_POLICY_BLOCK | Provider, response DLP (secrets) |
| 04 | pack-04-ks-global.json | BLOCK | KILL_SWITCH_ACTIVE_GLOBAL | Kill switch, global scope |
| 05 | pack-05-ks-provider.json | BLOCK | KILL_SWITCH_ACTIVE_PROVIDER | Kill switch, provider scope |
| 06 | pack-06-ks-model.json | BLOCK | KILL_SWITCH_ACTIVE_MODEL | Kill switch, model scope |
| 07 | pack-07-ks-agent.json | BLOCK | KILL_SWITCH_ACTIVE_AGENT | Kill switch, agent scope |
| 08 | pack-08-mcp-allow.json | ALLOW | NO_MATCH | MCP tool, bilateral classification |
| 09 | pack-09-exec-block.json | BLOCK | EXECUTION_POLICY_BLOCK | MCP tool, execution DLP (secrets) |
| 10 | pack-10-mcp-response-block.json | BLOCK | RESPONSE_POLICY_BLOCK | MCP tool, response DLP (PII) |
| 11 | pack-11-ks-tool.json | BLOCK | KILL_SWITCH_ACTIVE_TOOL | Kill switch, tool scope |
| 12 | pack-12-tool-suspended.json | BLOCK | TOOL_SUSPENDED | Tool lifecycle enforcement |
| 13 | pack-13-caller-not-authorized.json | BLOCK | TOOL_CALLER_NOT_AUTHORIZED | Bilateral tool access control |
| 14 | pack-14-s2a-allow.json | ALLOW | NO_MATCH | System-to-agent governance |
| 15 | pack-15-entity-not-registered.json | BLOCK | ENTITY_NOT_REGISTERED | Default-deny identity enforcement |
| 17 | pack-17-mcp-continuation.json | ALLOW | NO_MATCH | Workflow chain root |
| 18 | pack-18-provider-continuation.json | ALLOW | NO_MATCH | Workflow chain continuation |
Go 1.21 or later. No external dependencies beyond the Go standard library and github.com/google/go-cmp (test only).
git clone https://github.com/scarpprotocol/scarp-verify.git
cd scarp-verify
go build -o scarp-verify .
Evidence packs are signed with RS256 using a key pair held in the customer's key management system. To verify signatures, you need the corresponding public key in PEM format. The corpus packs in this repository were signed with key fingerprint 99349b7fad0c44c3. The public key for corpus verification is at samples/corpus/public-key.pem.
./scarp-verify single --pack samples/corpus/pack-01-provider-allow.json --key samples/corpus/public-key.pem
Exit codes: 0 (valid), 1 (integrity failure), 3 (malformed input).
The tool reconstructs the canonical hash independently using RFC 8785 (JSON Canonicalization Scheme), zeroing pack_integrity_hash and pack_signature before hashing, and compares the result against the RS256 signature using the provided public key. See CANONICALIZATION.md for the full construction.
./scarp-verify batch --dir samples/corpus/ --key samples/corpus/public-key.pem
Verifies all 17 packs. Reports per-pack results and a summary. Any single failure fails the batch.
./scarp-verify chain --dir samples/corpus/ --key samples/corpus/public-key.pem --workflow fbd317d6-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Chain mode filters packs by workflow_id, orders them by workflow_action_index, verifies each pack's signature, and validates that each pack's prior_pack_hash equals SHA-256 of the preceding pack's pack_signature. A break in the chain (missing pack, reordered pack, tampered signature) produces exit code 1 with a diagnostic identifying the break point.
Modify any field in a pack file and re-run verification:
cp samples/corpus/pack-01-provider-allow.json /tmp/tampered.json
# Edit any field in /tmp/tampered.json
./scarp-verify single --pack /tmp/tampered.json --key samples/corpus/public-key.pem
# Exit code 1: canonical hash mismatch detected before signature verification
The tool detects tampering at the hash layer (canonical hash of the modified pack does not match the stored pack_integrity_hash) before it reaches signature verification. Both checks are independent: a tampered pack fails even if the attacker does not have access to the signing key.
The full canonicalization and signing construction is documented in CANONICALIZATION.md. The short version: RFC 8785 JSON Canonicalization Scheme, with pack_integrity_hash and pack_signature zeroed before hashing, SHA-256 hex digest as the integrity hash, RS256 signature over the hash bytes. The current signature algorithm identifier is rs256-double-hash-v1; see CANONICALIZATION.md for the historical context on the double-hash construction.
- Scarp Protocol
- Companion paper: "Governable AI from the Ground Up"
- CANONICALIZATION.md (signing construction reference)
See PATENTS.md.
Source code: Apache-2.0. See LICENSE.
Documentation: © 2026 Victor Davidenko. All rights reserved.