AlgoVoi open Decision chain (Apache-2.0): Passport + Mandate + Policy + Gate + Guardrail + Cancellation + Refund + Trust query + Execution + Orchestrator + Delegation + Revocation + Journey + SDK

[chopmob-cloud]

Latest (2026-07-09): 10 independent JCS implementations

The open conformance corpus is now cross-validated byte-identical across 10 independent JCS implementations in 10 languages. Elixir (jcs 0.2.0, pzingg) and Kotlin/JVM (erdtman/java-json-canonicalization 1.1) join Python, Node.js, Go, Rust, Java, PHP, .NET and Ruby, executed directly across 11 of the 14 anchor sets, with an independent three-way byte diff on every set. Corpus: https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors

The AlgoVoi Keystone

The Keystone is the complete decision chain behind an agent payment, expressed as one recomputable sequence of content-addressed references. Each link answers one question and binds to the next, so the whole chain verifies end to end offline, with no issuer contact: just RFC 8785 JCS canonicalization and SHA-256. Open, Apache-2.0.

The agentic lifecycle: identity to settlement. The Keystone chain in full, each reference sha256: over JCS (RFC 8785) of its predecessor:

passport_ref  ->  mandate_ref  ->  policy_bound_ref  ->  decision_ref  ->  execution_ref  ->  trust_query_ref


 who is it?       what may it      under which            was it            what did it?        one verdict


                  spend?           policy?                authorized?

Recompute any input field and the reference at that step plus every downstream reference diverges. One agent, one authority, one policy, one decision, one execution -- the whole chain is verifiable end to end with no issuer contact, using only JCS (RFC 8785) and SHA-256.

The agentic lifecycle extends through the full post-decision sequence: a settlement attestation binds to the exact execution_ref the Keystone produced; a refund anchors to the same; an audit chain of frames links execution, settlement, and refund by prev_hash and caps them with one trust_query_ref. Cancellation closes the mandate before execution on the authority-side mirror. Any party recomputes the full agentic lifecycle offline -- same JCS + SHA-256 discipline, no new primitive, no AlgoVoi software in the trust base. Agentic lifecycle -- composition proofs, byte-for-byte verifiable offline: https://docs.algovoi.co.uk/keystone

Cross-party (multi-agent): delegation -> revocation -> journey. The constructions are open source (delegation published; revocation and journey available on request); the cross-party proofs are the commercial Orchestrator.

Verify the whole chain yourself, no package import, offline:

git clone https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors


cd algovoi-jcs-conformance-vectors


python composition/verify_corpus.py

Each link below is its own open package: install it, pin it, verify it independently, or compose the whole chain. Every package is Apache-2.0 and pinned at 0.1.0; pinned adopters receive a free v0 verification key (pin, then key).

1. Agent Passport, passport_ref (identity)

Who the agent is, as a content-addressed identity reference.

2. Payment Mandate, mandate_ref (authority)

What the agent may spend, bound to its passport.

3. Policy Binding, policy_bound_ref (policy in force)

Which policy snapshot the action runs under, version provable and rotation detectable.

4. Compliance Gate, gate_ref (compliance verdict)

The no-PII compliance verdict, bound to the policy it assessed.

Compliance binding and decision basis (commercial)

The open Compliance Gate above emits the verdict. Substrate 2 binds that receipt into the keystone as a screen stage, proving the screening that informed this exact decision, and adds the signed decision basis: which compliance standards drove the verdict, the jurisdiction check bound to its geo determination, no PII and recomputable offline. Commercial only. Details: https://docs.algovoi.co.uk/keystone

5. Spend Guardrail, guardrail_ref (pre-payment decision)

The ALLOW or DENY decision, bound to agent, mandate and policy.

6. Execution, execution_ref (decision-bound execution evidence)

What the agent actually did, bound to the exact decision that authorized it. execution_ref is the natural replacement for action_ref, the keystone-bound successor on the same JCS (RFC 8785) and SHA-256 discipline; action_ref stays fully backward compatible as the legacy primitive, unchanged in the substrate, so existing integrations keep verifying byte for byte with no forced migration. New work targets execution_ref; action_ref keeps working.

7. Cancellation, cancellation_ref (closes the authority)

Closes the mandate before execution, bound to the exact mandate.

8. Refund, refund_ref (after settlement)

A refund anchored to the execution that committed, not merely to the decision.

9. Composite Trust Query, trust_query_ref (one verdict over the chain)

One recomputable trust verdict over the ordered chain of references. The same verdict serves as a settlement attestation: the settled chain is recomputable from the receipt alone, with no issuer contact.

Preconditions and transport, same pattern:

Substrate Guard, profile_ref (input-bounds gate)

The input-bounds profile every record is admitted under before canonicalization.

Flow-point hardening (open)

Three recomputable securing refs now deepen the Keystone where a bare ref proved a fact was recorded but not that it was recorded correctly or freshly: a decision-audit binding (a decision to the exact passport, mandate, policy-binding and compliance screen it consumed), an admission guard-context binding, and an integer-millisecond freshness window. Public conformance vectors recompute with SHA-256 and RFC 8785 only. pip install --extra-index-url https://pip.algovoi.co.uk/simple/ algovoi-keystone-secure-lite

PEF Keystone (signed transport frames)

Wraps and pins a Keystone reference into hash-linked evidence frames.

TAP Verifier (offline-verifiable agentic payment receipt)

Verifies an AlgoVoi TAP receipt with no AlgoVoi software: it re-derives the receipt_id from the JCS preimage and checks the Ed25519 signature using public libraries only, with an optional Falcon-1024 post-quantum check. For the Trusted Agent Protocol post-authentication audit trail.

CloudEvents adapter (keystone decision as a CloudEvents 1.0 event)

Emits an AlgoVoi keystone decision as a CloudEvents 1.0 event; the content-addressed execution_ref is the event id, and a consumer recomputes it from the event data with JCS (RFC 8785) and SHA-256, with no AlgoVoi software.

W3C Verifiable Credential adapter (keystone decision as a credential)

Emits an AlgoVoi keystone decision as a W3C Verifiable Credential (Data Model 2.0) of its own KeystoneExecutionCredential type; the content-addressed execution_ref is the credentialSubject id, recomputable from the subject before any signature suite is applied.

MCP verifier (recompute a keystone execution_ref in any MCP client)

An open Model Context Protocol server exposing keystone verification as tools, so any MCP client recomputes and checks a keystone execution_ref offline, with no AlgoVoi service.

Webhook verifier (verify a keystone ref in a webhook)

Verifies an AlgoVoi webhook's HMAC signature and recomputes the keystone execution_ref carried in the event from its fields with JCS (RFC 8785) and SHA-256, so a consumer proves both the signature and that the keystone reference is authentic, with no AlgoVoi software.

LangChain run trace (keystone decision on a LangChain run)

Attaches a keystone decision to a LangChain run as metadata and a tag under algovoi.keystone.*, so LangSmith or any tracer shows a content-addressed execution_ref a reviewer recomputes from the run alone, with no AlgoVoi software.

CrewAI step trace (keystone decision on a CrewAI step)

Records a keystone decision once via a CrewAI step callback and passes the step output through unchanged, so a crew run carries a content-addressed execution_ref recomputable from the recorded metadata alone, with no AlgoVoi software.

AutoGen message trace (keystone decision on an AutoGen message)

Stamps a keystone decision into an AutoGen message's metadata, so a conversation carries a content-addressed execution_ref recomputable from the message alone, with no AlgoVoi software.

ADK agent trace (keystone decision in Google ADK agent state)

Stamps a keystone decision into Google ADK agent state via a before-agent callback, so an agent run carries a content-addressed execution_ref recomputable from the state alone, with no AlgoVoi software.

Orchestrator and composition proofs

The Keystone Orchestrator produces verifiable, end to end evidence that authority flowed correctly across organizational boundaries and was not exceeded, recomputable offline. The signed verdict is portable: it verifies off-the-shelf as a standard EdDSA JWS under any JOSE library and as a W3C Verifiable Credential under the Digital Bazaar eddsa-jcs-2022 suite, with no AlgoVoi software. Composition proofs are available on request. Docs: https://docs.algovoi.co.uk/keystone

Delegation: authority across parties (delegation_ref)

When authority is handed from one party to another, the Orchestrator proves it composed without anyone exceeding their grant. A treasury agent A, authorized for payments up to 1000 across GB and US, delegates a slice to a vendor agent B for a fixed window. B decides and executes deliberately narrower (a USDC transfer up to 500, GB). The Orchestrator composes A's authority, the delegation, B's decision and B's execution into one signed verdict: authority flowed correctly across the A to B boundary and nothing was exceeded, verifiable offline. If B instead executes for 2000, the verdict is BROKEN: a signed receipt would still look valid, the composed proof does not.

The open delegation_ref is the tamper-evident binding for each hand-off. The cross-party scope-consistency proof is the Orchestrator capability; composition proofs available on request.

Revocation: pulling authority back (revocation_ref)

Authority can be withdrawn before it expires. When a grantor revokes a delegation, the Orchestrator proves that every downstream action which happened at or after the revocation no longer holds, even across several hops. A treasury agent A delegates to B, B sub-delegates to C, then A revokes the original grant. Any action C takes after that revocation composes to BROKEN, because C's authority derived from a grant A had already pulled, recomputable offline. An action that happened before the revocation stays valid: revocation is prospective and provable from the bytes, not a mutable status flag. The open revocation_ref is available on request (Apache-2.0); the cross-party cascade proof is the commercial Orchestrator capability.

Journey: the whole multi-agent task as one proof (journey_ref)

One reference binds an entire multi-agent task end to end: every hop's execution and the delegations between them. Verifying a single journey_ref proves the whole A to B to C task at once: identity and authority continuity, scope never widened at any boundary, nothing acted under a revoked grant, and no hop omitted from the record. Drop a hop or widen scope anywhere and the journey composes to BROKEN. The open journey_ref is available on request (Apache-2.0); the end to end aggregation proof is the commercial Orchestrator capability.

Journey adapters: bind the whole run in your framework (commercial)

The CrewAI, LangGraph, AutoGen, and A2A journey adapters each record a multi-agent run's hops and the delegations between them, then emit one journey_ref over the whole task: a crew, a graph, a group chat, or an agent-to-agent task verifies as a single proof.

Commercial full Orchestrator (delegation proofs + PQC sign + CCC): in the on-prem bundle.

IETF drafts

Internet-Drafts for the underlying constructions (the canonicalization substrate, the receipt and execution references, and the audit chain of frames) are available on request.

Benchmark, clean-box reproduction

Reproduced on a clean box, a fresh container with one vCPU, installing only from the public PyPI and npm registries:

• All 22 packages (11 PyPI, 11 npm) install and import on a clean box.

• Full conformance corpus v0.26.0: 31 vector sets plus every composition keystone reproduce byte for byte, Node equals Python.

• Single core soak, zero drift: 19,171 keystone recomputations per second on Python and 40,296 per second on Node, with zero drift across roughly 1.78 million recomputations.

---

Security testing (last run 2026-07-01)

Canonicalization fuzz (2026-06-22): adversarial differential testing across 9 independent JCS implementations. 20,000 safe-domain inputs: 0 divergences. 373 adversarial (out-of-domain) inputs: the substrate's own canonicalizer fail-closed on 373/373 -- zero in-domain breaks. Public attestation in the conformance-vectors repository.

Cross-implementation parity (corpus v0.31.0): conformance vectors validated byte-identical across 8 independent implementations in 8 languages -- Python, Node.js, Go, Rust, Java, PHP, .NET, Ruby. Node equals Python on every reference.

Keystone conformance (2026-07-01): 16/16 conformance tests -- determinism, byte-for-byte recompute, tamper divergence (any field change diverges every downstream reference), severity weighting, and chain binding. Fresh-venv clean install verified against corpus v0.31.0; 7-tier keystone recompute byte-for-byte.

Input-bounds gate (algovoi-substrate-guard, Apache-2.0): runs before canonicalization and admits only inputs within the proven safe domain (safe-integer range, Unicode scalar validity). 15/15 public test vectors. On PyPI and npm.

Substrate 2 (Commercial)

Everything above is open (Apache-2.0). Substrate 2 is the commercial core built on the same canonical evidence, with two simple parts.

The control plane: where the pieces connect. Think of it as the switchboard. Every service (payments, compliance, records, evidence) plugs into one hub that keeps the single list of trusted keys and issuers, lets each service register itself, and shows one live view of the whole system's health.

The keystone: the record of what actually happened. A payment is checked for authorization, a decision is made, it executes, and it settles on chain. The keystone stitches those steps into one tamper-evident thread: each step is a short fingerprint locked to the one before it, so the whole story, from "allowed to spend" to "settled," re-checks offline with no AlgoVoi software. The same record exports as a signed JSON receipt, a W3C Verifiable Credential, a JOSE token, or a zero-knowledge proof, each pointing back to the same payment.

The control plane connects the apps; the keystone is the thread that runs through a payment.

Run it yourself. A self-hosted Payment Rails bundle installs the control plane and keystone on your own infrastructure and speaks all four protocols (x402, MPP, AP2, A2A) across seven chains. It starts on SQLite for a five minute install and upgrades to PostgreSQL by import. The encrypted bundle verifies its licence and installs fully offline. Details: https://docs.algovoi.co.uk/payment-rails-sqlite

Details: https://docs.algovoi.co.uk/substrate-2

Keystone config panel

The keystone is an evolving ecosystem: each step has configurable parameters that shift as the platform grows. algovoi-keystone-control surfaces those parameters in a browser UI, auto-detects which algovoi packages are installed, and lets operators edit them via a pin-gated HTTPS panel. Open (Apache-2.0).

Docs: https://docs.algovoi.co.uk/keystone

Keystone connectors -- drop-in adapters that bind a data-layer operation to the keystone decision that authorised it, emitting a content-addressed execution_ref (verifiable offline with keystone-verify. Open Apache-2.0, available on request):

• algovoi-keystone-odbc -- wraps any ODBC / DB-API cursor; every execute (insert / update / delete) is bound to its decision_ref, so a write can be proven consistent with the decision that allowed it.

  

• algovoi-keystone-sqlalchemy -- one bind_session() call registers an after_flush listener; each flushed ORM change is bound to the keystone, no model or query changes.

  

• algovoi-keystone-kafka -- wraps any producer (kafka-python / confluent-kafka / aiokafka); each produced message carries an execution_ref, with failed sends recorded as FAILED.

  

• algovoi-keystone-openlineage -- attaches a keystone run facet to each OpenLineage RunEvent, so the lineage standard's own events carry the execution_ref; outcome derived from eventType.

  

• algovoi-keystone-asgi -- one ASGI / WSGI middleware (FastAPI / Starlette / Flask / Django) binds every state-changing HTTP request to its decision_ref; outcome from the response status.

  

• algovoi-keystone-grpc -- a gRPC server interceptor binds each unary call to its decision_ref; outcome COMMITTED, or FAILED if the handler raises. Streaming passes through.

  

• algovoi-keystone-s3 -- wraps any boto3 S3 client so every object write (put / delete) carries an execution_ref keyed to bucket/key; reads pass through untouched.

  

• algovoi-keystone-redis -- wraps any redis-py client so every write command (set / delete / hset / expire / ...) carries an execution_ref keyed to the key; reads pass through.

  

• algovoi-keystone-mongo -- wraps any pymongo collection so every write (insert / update / delete / replace) carries an execution_ref keyed to db.collection; reads pass through.

  

• algovoi-keystone-amqp -- wraps any pika channel so every AMQP / RabbitMQ publish carries an execution_ref keyed to exchange/routing_key; consumers and declares pass through.

  

• algovoi-keystone-elasticsearch -- wraps any elasticsearch-py client so every write (index / update / delete / bulk) carries an execution_ref keyed to index/doc_id; searches pass through.

  

• algovoi-keystone-nats -- wraps any nats-py connection so every publish carries an execution_ref keyed to the subject; subscribes and requests pass through.

  

• algovoi-keystone-gcs -- wraps any Google Cloud Storage blob so every object write (upload / delete) carries an execution_ref keyed to bucket/name; reads pass through.

  

• algovoi-keystone-azure-blob -- wraps any azure-storage-blob container client so every object write (upload / delete) carries an execution_ref keyed to container/blob; reads pass through.

  

• algovoi-keystone-azure-servicebus -- wraps any azure-servicebus sender so every send (send_messages / schedule_messages) carries an execution_ref keyed to the queue or topic; receivers pass through.

  

• algovoi-keystone-httpx -- wraps any httpx.Client / requests.Session so every outbound state-changing call (POST / PUT / PATCH / DELETE) carries an execution_ref keyed to host/path; reads pass through.

  

• algovoi-keystone-celery -- wraps a Celery task or app so every dispatch (apply_async / delay / send_task) carries an execution_ref keyed to the task name; a dispatch that raises is recorded FAILED.

  

• algovoi-keystone-sqs -- wraps any boto3 SQS client so every send (send_message / send_message_batch) carries an execution_ref keyed to the queue name; receives pass through.

  

• algovoi-keystone-sns -- wraps any boto3 SNS client so every publish carries an execution_ref keyed to the topic; reads pass through.

  

• algovoi-keystone-pubsub -- wraps any google-cloud-pubsub PublisherClient so every publish carries an execution_ref keyed to the topic; other calls pass through.

  

• algovoi-keystone-dynamodb -- wraps any boto3 DynamoDB client so every write (put / update / delete / batch) carries an execution_ref keyed to the table; reads pass through.

  

• algovoi-keystone-pinecone -- wraps any Pinecone Index so every vector write (upsert / delete / update) carries an execution_ref keyed to index/namespace; reads pass through.

  

• algovoi-keystone-qdrant -- wraps any QdrantClient so every vector write (upsert / delete / payload) carries an execution_ref keyed to the collection; reads pass through.

  

Companion verifier -- algovoi-keystone-validate ingests a batch of these execution_ref records, recomputes each offline, checks they bind to the expected decision, and logs what failed and why (integrity vs operational errors). Open Apache-2.0, available on request.

How to verify (no trust required) -- every reference is content-addressed: ref = "sha256:" + SHA-256(RFC 8785 JCS(object)). You can reproduce any published reference with a third-party RFC 8785 implementation and standard SHA-256, with no AlgoVoi software involved:

import rfc8785, hashlib   # independent RFC 8785 implementation


obj = {"agent_id": "agent-001", "issuer": "did:algo:issuer",


       "scope": "payments", "validity_window": "2026-06-21/2026-09-21"}


print("sha256:" + hashlib.sha256(rfc8785.dumps(obj)).hexdigest())


# -> sha256:b3594e33998af01bd1ad208172c5c1ac586daa8c75781379f034d97e50b1a9be

That reference is byte-identical to the published corpus value for this identity object, computed with a different canonicalizer than the one inside the package -- so a match proves the substrate is faithfully the open standard, not something you take on trust. Change any field and the reference diverges. RFC 8785 implementations exist in Go, JavaScript, Rust, and Java; any reproduces the same bytes. The conformance corpus is keyed under the jcs-rfc8785-v1 profile. The one-command verifier that recomputes the full chain byte-for-byte against the Ed25519-signed conformance corpus (fully offline, trusts no emitter) is open Apache-2.0, available on request.

Install (from the AlgoVoi index):

pip install --extra-index-url https://pip.algovoi.co.uk/simple/ algovoi-verified

The full open Keystone fleet is on the same index: https://pip.algovoi.co.uk/simple/

The Keystone control panel is published on PyPI:

pip install algovoi-keystone-control

The tested packages themselves are served from the AlgoVoi index to preserve their integrity and security.

x402 payment receipts (verifiable offline)

The keystone execution stage produces an x402 payment receipt: a signed record binding the payment evidence to the exact authorization that approved it, verifiable offline with JCS (RFC 8785) and SHA-256 using any conforming canonicalizer. Three reference pages on the receipt construction and its properties:

• Verifiable x402 receipt -- the receipt format, preimage construction, and signature scheme. Any verifier with an RFC 8785 implementation and standard Ed25519 library recomputes the receipt identifier and checks the signature with no AlgoVoi software. Details: https://docs.algovoi.co.uk/verifiable-x402-receipt

• Offline-verifiable receipts -- the full offline verification method, including the step-by-step preimage derivation, the Ed25519 signature check, and the optional Falcon-1024 post-quantum layer. Details: https://docs.algovoi.co.uk/offline-verifiable-receipts

• No-PII compliance receipt -- the compliance gate verdict feeds the receipt directly, so a recipient verifies that no personal data was included in the payment evidence by recomputing the gate reference from the receipt alone. Details: https://docs.algovoi.co.uk/no-pii-compliance-receipt

Live proof: the Keystone across six chains

The Keystone trust chain now has a live, end to end proof. We compose the full chain (passport, mandate, policy, signed decision, execution, and a single trust query), bind it to a real on-chain settlement, and verify every reference and signature offline. It has been tested across six public testnets: Base Sepolia, Arc, Tempo, Algorand, Stellar, and Solana. On Algorand, Stellar and Solana the decision is written into the transaction itself (the note, memo and reference), so it is visible directly on the block explorer.

The same chain also composes across four agent-payment protocols (x402, MPP, AP2, A2A), which converge on one settlement reference. A downloadable proof pack and an independent verifier (SHA-256, RFC 8785, Ed25519 only) are included.

Walkthrough, the live transactions, and a recompute it yourself guide: https://docs.algovoi.co.uk/keystone-proof

[chopmob-cloud]

Keystone Control Panel (open, Apache-2.0)

A browser-based settings panel for the keystone ecosystem, available on request.

What it does

Auto-detects installed algovoi keystone packages and shows their configuration in one place. Each installed step gets its own settings row (gate config) and a substrate tab for the low-level canonicalisation variables (canon_version, hash_algo, required_fields, chain_requires). Read access is open; edit is gated.

Login and pin gate

Two-tier access. A session token unlocks the view. A separate Falcon-1024 licence key unlocks editing. The licence key check is fully offline: signature verified against a bundled issuer public key, no network call. Keys are issued per deployment and last 90 days via a persisted pin cookie. Rate limiting (5 attempts per 60 s) and httponly / samesite cookies are in place.

HTTPS

Ships with a generate_ssl.sh script. Each deployment generates its own self-signed RSA 4096 cert (openssl, SAN covers the local hostname and loopback). Uvicorn loads it at startup via --ssl-keyfile / --ssl-certfile.

Screenshot: login

Screenshot: panel with guard step detected

The panel shows 1 installed step (guard) and 9 not yet installed. The guard step (guard_ref, posture: Input bounds + DoS gate pre-canon, v0.1.0) comes from algovoi-substrate-guard, which sits upstream of canonicalisation and is open / Apache-2.0 on PyPI.

Available on request. requires-python = ">=3.11" (Falcon-1024 wheel constraint).

Bring any variable, Keystone supports it (alias mapping, now live)

Keystone does not hard-code a fixed set of layers. Any ref you define can be declared an alias of a canonical Keystone layer, and it then appears in the chain at that layer's position and recomputes the same way. Two paths, neither needs a catalogue edit or a rebuild:

• Package bolt-on: your package ships an algovoi.keystone.steps entry point carrying alias_of, and the control panel discovers it on install.
• Operator, at runtime: map any ref onto a canonical Keystone ref directly in the panel; it persists across restarts.

[chopmob-cloud]

Keystone Control Panel: bolt-on ecosystem

The control panel is not just a settings UI. Each keystone stage is a defined integration surface. Any vendor whose package emits conformant content-addressed refs plugs straight in. The panel detects it, surfaces its config, and validates it against the chain's canon_version before activating it.

Stage surfaces

Stage	Ref	Bolt-on categories
Identity	passport_ref	KYC (Jumio, Persona, Sumsub), W3C VC issuers, DID resolvers, biometric attestation, Gov ID verify, OIDC
Authority	mandate_ref	Smart contract mandates, multi-sig approval, DAO governance, corporate hierarchy, spending limit oracles
Policy	policy_bound_ref	GDPR / PSD2 / MiCA engines, jurisdictional rule sets, live regulatory feeds, legal smart contracts, insurance underwriting
Compliance	screen_ref	Chainalysis, Elliptic, OFAC/SDN, PEP screening, transaction monitoring, risk scoring ML, SAR filing
Decision	guardrail_ref	Fraud detection models, velocity rules, credit decisioning, real-time market data, custom risk rules
Execution	execution_ref	Per-chain settlement providers, FX conversion, multi-rail routing, atomic swaps, bank ACH/SEPA, card rails
Verdict	trust_query_ref	Accounting (Xero / QuickBooks), tax reporting, data warehouse connectors, SIEM, regulatory reporting

Cross-party layer

delegation_ref (multi-agent authority chains), revocation_ref (live revocation registries), journey_ref (cross-org aggregation) — plus agent framework observability (LangChain, CrewAI, AutoGen) and W3C VC verifiers, all wired to the same spine.

How bolt-ons work

The entry point is open. Any package that registers algovoi.keystone.steps appears in the panel automatically. No approval process for the entry point itself.

Conformance is about interoperability, not permission. A bolt-on that emits a valid content-addressed ref using the JCS + integer-ms substrate can be verified by any other step in the chain, by any org, offline. The substrate is the shared language. The conformance check just confirms the bolt-on speaks it, so downstream steps can trust what it produces.

Self-hosted today. A discoverable registry of conformance-validated bolt-ons is the natural next layer once the ecosystem has volume.

[chopmob-cloud]

How to build a Keystone bolt-on

The keystone control panel auto-detects bolt-ons through one small contract, so you can add your own step and have it recognised without us changing anything.

A bolt-on is a Python package that declares an entry point and returns a short descriptor.

1. Declare the entry point in pyproject.toml:

[project.entry-points."algovoi.keystone.steps"]
my_step = "my_package.keystone:keystone_step"

2. Implement the callable. It returns a dict; step and ref are the only required keys:

def keystone_step():
    return {
        "package": "my-package",     # your distribution name
        "step": "my_step",           # the decision-flow stage you cover
        "ref": "my_ref",             # the *_ref your package emits
        "order": 50,                 # optional: where it sits in the flow
        "posture": "what it does",   # optional: one line
    }

3. Install it alongside algovoi-keystone-control and confirm:

keystone-verify my-package
# PASS  my-package is Keystone Enabled -> step 'my_step' (emits my_ref, via entry-point)

That is the whole contract. Publish your package and anyone with the panel installed sees your step.

Two tiers: Keystone Enabled (your package produces a keystone ref at a step, as above) and Keystone Integration (a keystone-* tool that consumes, exports, or verifies keystone evidence). More: https://docs.algovoi.co.uk/keystone

[chopmob-cloud]

⚡ New (open, Apache-2.0): algovoi-keystone-connect -- build and test a Keystone bolt-on in minutes

Bolting onto the Keystone just got a lot smaller. Two halves: build a data-plane connector from a declarative spec, and test any bolt-on at any stage of the chain, fully offline.

Build a connector, the whole thing:

from algovoi_keystone_connect import connector

keystone_s3 = connector("s3", writes={
    "put_object":    ("put",    lambda call: f"{call.kwargs['Bucket']}/{call.kwargs['Key']}"),
    "delete_object": ("delete", lambda call: f"{call.kwargs['Bucket']}/{call.kwargs['Key']}"),
})
client = keystone_s3(boto3_s3, decision_ref=decision_ref)
client.put_object(Bucket="receipts", Key="2026/r1.json", Body=b"{}")   # bound, offline-verifiable

That replaces about 130 lines of hand-written wrapper, and the emitted execution_ref is byte-identical to the long-hand version.

Test at any stage, no live gateway:

from algovoi_keystone_connect import check_connector, check_ref_builder, synth_ref

check_connector(keystone_s3, FakeS3(), [("put_object", {"Bucket": "b", "Key": "k"})]).ok
check_ref_builder(mandate_ref,
                  {"passport_ref": synth_ref("passport"), "cap": "500USD"},
                  prev_field="passport_ref").ok

synth_ref(stage) stands in for whatever precedes your bolt-on. The battery checks recompute, decision-binding, tamper-evidence, and predecessor-binding. A connector that ignores its decision_ref, or a ref-builder that is not content-addressed, fails.

It all reduces to one primitive: ref = "sha256:" + SHA-256(RFC 8785 JCS(payload)). No AlgoVoi software in your trust base. Pure Python and readable.

Install it from the Keystone control panel. More: the connector catalogue at https://docs.algovoi.co.uk/keystone-connectors and the chain at https://docs.algovoi.co.uk/keystone

---

Update -- the toolkit is now a full SDK: algovoi-keystone + the keystone CLI (open, Apache-2.0)

One install brings the whole bolt-on toolchain, and one command drives it:

pip install algovoi-keystone

keystone new redis-stream --kind connector   # scaffold a bolt-on, green out of the box
keystone test                                 # recompute, decision-bound, tamper-evident
keystone validate records.json                # verify any emitted ref offline
keystone journal run.db                        # verify a run's evidence journal

Three layers landed on top of the connector builder, all reducing to the one primitive ref = "sha256:" + SHA-256(RFC 8785 JCS(payload)):

• Agent behaviours -- declare rules, triggers and behaviours and gate any write before it commits; every firing is a content-addressed behaviour_ref. https://docs.algovoi.co.uk/keystone-agent
• Runtime and journal -- run a chain and keep the evidence in a tamper-evident SQLite journal that recomputes offline. https://docs.algovoi.co.uk/keystone-runtime
• One import surface -- from algovoi_keystone import connector, behaviour, Engine, Runtime, keystone_ref.

No AlgoVoi software in your trust base: every reference recomputes with a stock RFC 8785 implementation and standard SHA-256. Install it from the Keystone control panel. Docs: https://docs.algovoi.co.uk/keystone-sdk

[chopmob-cloud]

Direct agentic integration for the Passport step: present and verify, both sides of the wire

The Passport in this chain now has a drop-in agentic path, offline and stock-tool verifiable.

An agent presents its passport on an outbound x402 or A2A call: a Falcon-1024 (FIPS 206) credential binding the agent DID to scopes, a spend bound and an expiry. A relying party verifies a presented passport fully offline, against the issuer's published key, with a stock trust base (RFC 8785 JCS plus a FIPS 206 verifier) and no service in the trust path. Verification is fail closed: with no key resolved or no revocation confirmed the verdict is unverifiable, never a default trust, and the kid is bound to the key (sha256 of the public key) so a swapped key cannot validate.

Two pieces, both live:

• a client to present and verify offline, and
• an agent SDK: a holder that attaches the passport to an outbound call, and a guard that admits or denies on a policy of scopes, a spend floor and an allowed-agent list (a one-line dependency gates an endpoint).

It composes with the rest of the chain on one primitive: a verified passport is a content-addressed keystone record (ref = sha256(RFC 8785 JCS(payload))), so it validates and journals in a tamper-evident chain alongside Mandate, Execution and the rest. The passport signature carries authenticity; the chain carries composition.

Discoverable through the Keystone Control Panel. Reference: https://docs.algovoi.co.uk/keystone