Skip to content
How it works

How one record gets made.

One signed account of what every authorized actor on a multi-vendor site did, when, and under whose approval. This page follows that record end to end: chartered, admitted, approved, sealed, proven.

The signer runs on a confidential-compute appliance at the site (a hardware TEE), not on the robot. Receipts use open standards (COSE / Ed25519, aligned with IETF SCITT) and verify with tools you do not buy from us.

Reference site · Wilder
Charter · SignedSample data
Site
Wilder Management Reference Site
Operator
Wilder Management
Charter version
v1.0
Charter expiration
2027-06-20expires in 346 days
Mesh participants
5 devices
CL distribution
CL-1×1CL-2×2CL-3×2
Sealed receipts
3 in chain
Three-tier consent
all 3 tiers in place
The five-artifact stack
derivation order

Each artifact is derived from the one above it. Read top to bottom: a site becomes a set of rules, participants prove what they can do, work is named and bounded, every run is signed.

  1. 01

    What is this site, and who is allowed to act on it?

    The plain-English founding document: the root and trace-anchor. A non-engineer reads it in under five minutes. Everything below is derived from it.

  2. 02

    Site Policies

    no dedicated screen

    What rules turn the Charter into permitted, prohibited, or conditional actions?

    The operator's rule layer, derived from the Charter and signed by the operator. Every Engagement Receipt references a policy via its approval_basis.

  3. 03

    Mesh Contract

    Who is admitted

    What can each device, robot, sensor, or subsystem actually do, and did it prove it?

    A W3C Verifiable Credential every participant MUST publish to join the site. A compliance overlay over ROS 2 / OPC UA, never a competing interface.

  4. 04

    Conversation Templates

    no dedicated screen

    What bounded, repeatable unit of work is being authorized?

    The named, versioned, reusable ops loop. Templates declare required capabilities from the Mesh Contract registry, not required vendors. Every run produces one receipt.

  5. run

    Engagements

    no dedicated screen

    What specific run is happening now, with which devices in which roles?

    The runtime step, not a persisted artifact: a single instantiation of an adopted Template with a concrete input set. The Planner assigns devices to roles from their Mesh Contract capabilities, mints a per-engagement nonce, and produces the receipt below.

  6. 05

    Engagement Receipts

    The Receipt

    What actually happened, who approved it, and who validated and verified it?

    The COSE multi-signer audit record: Approval → validator → reviewer → Pask Seal. Once sealed it is tamper-evident. Any change to any field invalidates all signatures.

One device, concretely

For the patrol robot you author its Mesh Contract (its navigate capability and ROS 2 transport), map that capability to the device’s real action interface (nav2 NavigateToPose on /navigate_to_pose), and a signed teachback challenge confirms the contract matches the device before it can take part in a sealed record.

For the device’s manufacturer, the boundary is the contract: devices join by signed Mesh Contract on the protocols they already speak, a device that cannot self-attest is represented by a gateway, being witnessed requires no firmware change, and the same signed record that attributes a loss also clears a machine that performed as authorized.

Three surfaces
Plannerpropose step

Propose. Pick a Conversation Template, assign devices to roles from their Mesh Contract capabilities, mint a per-engagement nonce. First step inside the Gate; never issues direct robot commands.

Meshopen →

The live device graph: every participant’s node type, vendor, capabilities, conformance level, contract status.

Gateopen →

Propose, approve, sign, seal. The four-signer pipeline assembles the COSE container, refuses robots with suspended contracts, and emits a sealed Engagement Receipt.

Who operates it

Whoever operates Pask (the site itself, a service partner, or a 3PL) does the same four things: holds the charter, staffs the validator and reviewer signer roles, runs the appliance, and answers for the record. Those roles are held by named, accountable operators.

Writes into what you already run

Pask seals the record and writes it back into the work-order, maintenance, or claim system you already run. It feeds your books; it does not replace them. The write adapter is part of the reference implementation: see Capability status.

"adapter": {
  "mode": "WRITE_ONLY",
  "system": "guidewire-claimcenter",
  "endpoint": "claim/FNOL-2026-0042"
}

Sample WRITE_ONLY payload; target illustrative. The adapter writes into the claim or work-order system you already run (Guidewire ClaimCenter, Duck Creek, a maintenance system) through an ACORD-shaped data contract. Pask never reads back.

Reference detailThe trust model, what runs where, and the limits of the record
The trust model

Who you have to trust for this to hold.

The site owner owns the box.

The physical premises, the appliance, and the cryptographic keys live with the operator. Pask holds no keys.

The TEE platform vouches for the key.

Hardware attestation lets an independent verifier check the signing environment against an approved hardware and software configuration in a Trusted Execution Environment.

Pask writes the vocabulary and the adapter.

We define the receipt schema (wilder.pser/0.2) and provide the verifier: downloadable today. The write-only adapter is part of the AGPLv3 reference implementation, which publishes with the first pilot. You run your operations; the record stays on your site.

What runs where

The Pask signer runs inside a TEE on hardware at your site, the same technology behind AWS Nitro Enclaves and Azure Confidential VMs, but on-premises where you can point at it. The silicon vendor’s remote-attestation service, not Pask and not the site owner, lets an independent verifier confirm the signing key sits in an approved configuration. Adding another TEE platform is a firmware change, not a spec change.

When Pask writes a record

Not every movement. Like a flight recorder, Pask captures the moments that carry weight, not the routine telemetry in between. A record is written at three kinds of boundary.

Authority

A new party, machine, or agent is granted permission to act: an admission, an approval, a handoff of control.

Consequence

An action carries legal, financial, safety, or contractual weight: a task sealed, a restricted area entered, a claim filed.

Exception

Reality diverges from the approved path: an override, a safety stop, a degraded sensor, a disputed outcome. A plan the Gate refuses never becomes an engagement and writes no receipt.

What the record establishes, and where it stops
Integrity

The sealed bytes have not changed since sealing.

Identity

The listed keys signed the record.

Authority

The action references an approved policy and device authorization.

Evidence

The sensor data, logs, and operator claims available at sealing time were included.

Pask does not independently determine causation, negligence, or physical truth. It preserves a verified account of the authorization, the actors, the declared actions, and the evidence available when the record was sealed.

Capability status
what is real today
Browser content hashing (SHA-256)
Working
Signature verification, ephemeral demo keys
Working
Local hash-chain continuity
Working
Attestation appraisal (allowlist + nonce)
Working
Transparency-log proofs in the browser (inclusion + consistency)
Working
Production hardware-attestation service
Reference
Trusted timestamp (RFC 3161)
Roadmap
Hosted transparency log
Roadmap
Customer-system write adapter
Reference
Device-protocol read path (ROS 2, OPC UA, MQTT)
Pilot target
Physical-robot receipt
Pilot target

Working: runs in your browser on this site · Reference: in the AGPLv3 reference implementation, publishes with the first pilot · Roadmap: designed, not yet built · Pilot target: proven first on the pilot site

The full record specthe Gate, the Receipt, Compliance, and where humans touch itRead the full spec
01
The Gate

Propose. Approve. Sign. Seal.

An engagement runs through a propose-then-commit gate and emits a signed, TEE-attested Engagement Receipt with four nested signers: Approval, validator, reviewer, Pask Seal.
What the record proves, and what it does not

A receipt proves that a named party approved the engagement, that the appliance witnessed and sealed the reported result, and that nothing changed after sealing. It does not, on its own, prove that a device’s self-reported telemetry was physically true; higher conformance levels add signed telemetry (CL-2) and TEE attestation (CL-3) to close that gap.

Engagement classes

Engagement classes are set by the operating model: a scheduled cadence visit, a fault response, a priority escalation. Pask records them all the same way. The engagement is the unit; the receipt is the record. Pricing and response windows belong to the service partner, not to Pask.

Who is admitted

Every participant (robot, sensor, service, person) joins the site under a signed Mesh Contract, a W3C Verifiable Credential declaring its capabilities up front and authored by the site or a gateway for devices that cannot self-attest. Each contract carries a conformance level:

  • CL-1 Schema-valid declared data only.
  • CL-2 Adds signed telemetry.
  • CL-3 Adds TEE attestation.
Planner · Conversation TemplateGate

A bounded interior patrol of a defined indoor zone during a defined overnight window. The Patroller traverses the zone, the Observer captures sensor readings at designated waypoints, the Reporter produces a coverage report. Anomalies above a configured threshold trigger escalation to the operator.

Template
overnight-interior-patrol · v1.3.0
Capabilities
navigate_2dtraverse_stairscapture_imageread_occupancyreport_status
Assign roles from participants

Patroller

needs navigate_2d · traverse_stairs

Patrol Robot 04CL-3

Observer

needs capture_image · read_occupancy

Dock Sensor ArrayCL-2

Reporter

needs report_status*

Patrol Robot 04CL-3

Only participants whose Mesh Contract declares the required capability are offered (* coordination capabilities are orchestrator-provided over the mesh, not declared per device). The Gate refuses any plan containing a robot with a suspended Mesh Contract. All Wilder participants are currently active.

Propose · commitmentPlanning
proposing_surface
pask://planner/wilder-mgmt-pilot/overnight-interior-patrol
engagement nonce
proposed_plan_hash
commit to compute

The plan is committed by hash, not embedded: the receipt proves what was proposed without disclosing it.

Policy engine: scripted preview
Four signers · six questions
  1. 0ApprovalWho approved it?
  2. RATS ATTESTATIONWhat was attested?
  3. EXECUTEWhat actually happened?
  4. 1validatorWho validated it?
  5. 2reviewerWho verified it?
  6. 3SealSealed tamper-evident?

The Engagement Receipt seals on completion

Propose, then run the Gate. Four nested signers produce a TEE-attested Engagement Receipt.

Why four signers: six questions, one record
01

What was proposed?

Committed by hash at the Planner: proposed_plan_hash, never embedded.

020Approval

Who approved it?

Signer 0: the approving party, with a basis citing a Charter section and site policy.

03

What was attested?

RATS attestation result on the on-site TEE, with a fresh Verifier nonce.

04

What actually happened?

Executing agents ran their capabilities; resources consumed and outcome_state recorded.

051validator

Who validated it?

Signer 1: the validator attests that execution matched the approved plan.

062reviewer

Who verified it?

Signer 2: reviewer independently verifies; Signer 3: Pask Seal makes it tamper-evident.

Gate refusal rule

The Gate refuses any plan containing a robot with a suspended Mesh Contract.

Role assignment offers only participants whose active Mesh Contract carries the required capability. An E-stop or safety-zone violation flips a node to suspended: uninvitable until re-attested.

02
The Receipt

The atomic unit of evidence.

A COSE multi-signer record: independently verifiable without trusting Pask. It is the human-readable artifact of the propose, approve, sign, and seal exchange: what was proposed, who approved it, what was attested, what actually happened, and who validated and verified it.
Wire formatthe exact strings a verifier reads
Content-Type
application/pser+json; profile=wilder.pser/0.2
Operator
site-operator@residential.example
Prior receipt · content address
sha256:3f4db878cc90aba50db8df9bdce376c4b1f805e5c35569885c2d4a794c9d0271
Receipt hash chaineach receipt commits (SHA-256) to the prior · site A1B2C3D4E5F6C0DE
PASK-00001boot

Boot / Genesis

prior_receipt_hash

genesis · nil
PASK-00041engagement

Overnight Interior Patrol

prior_receipt_hash

PASK-00042engagement

Floor Inspection

prior_receipt_hash

§5.1

Header

engagementschema v1.1alg_suite 2 · Ed25519 + ML-DSA-65

Which receipt is this, and what precedes it in the chain?

engagement_id (UUIDv7)
site_id
prior_receipt_hash
chains to prior
§5.2

Identity

TEE · amd-sev-snp

Under which Charter, Mesh Contract, and template did this run?

site_charter_version
1.0
mesh_contract_version
1.1.0
conversation_template_id
overnight-interior-patrol/1.3
pask_version
2.0.1
tee_identity.quote_reference
tee_identity.measurement_digest (SHA-384)
§5.3

Proposal

What was proposed? Plan committed by hash only, never embedded.

proposing_surface
pask://planner/wilder-mgmt-pilot/overnight-interior-patrol
proposed_plan_hash (SHA-256, JCS)
proposal_qtsp_token · RFC 3161 trusted-timestamp token, never NTP

Timestamp-authority integration is a pilot deliverable; tokens shown are sample data.

0ApprovalWho approved it?
approving_party
pask://human/operator-jhale
approval_basis (Charter § / policy)
charter-v1.0/policy-overnight-patrol/autonomous-mode
approval_signature (Ed25519 + ML-DSA-65)
approval_qtsp_token · RFC 3161 trusted-timestamp token, never NTP
§5.5

RATS Attestation

evidence · amd-sev-snp

What was attested? Fresh TEE evidence, verifier-checked.

rats_attester_id
urn:pask:attester:wilder-mgmt-pilot:snp-node-1
rats_evidence
rats_attestation_result (COSE)
rats_freshness_nonce (32-byte)
rats_verifier_public_key (DER)
§5.6

Execution

completed

What actually happened?

executing_agents

pask://agent/patrol-04navigate_2d
mesh_contract_id
mesh_contract_version
1.1.0
pask://agent/dock-sensorread_occupancy
mesh_contract_id
mesh_contract_version
1.1.0

resources_consumed

rtk_seconds · 45.2dock_minutes · 12kwh · 0.038
outcome_details (structured code)
patrol-route-alpha/all-zones-clear
sensor_health_status
all sensors nominal
execution_start_qtsp_token · RFC 3161 trusted-timestamp token, never NTP
execution_end_qtsp_token · RFC 3161 trusted-timestamp token, never NTP

Scope: these execution fields are reported by the device and sealed by the appliance. The receipt proves they were approved, witnessed, and unaltered since sealing, not that a self-reported value was physically true. CL-2 adds signed telemetry and CL-3 adds TEE attestation.

§5.7

reference_db_state

ABSENT, by design

No reference_db_state is present. This field exists only for biometric / access-control matching against a reference database. The Wilder site captures no biometrics (Illinois BIPA, 740 ILCS 14, the default). Receipts attest events and decisions, not identities, so there is no reference database to commit to.

1validatorWho validated it?
validator_signature_input_hash (SHA-256)
validator_ed25519_signature
validator_mldsa65_signature (FIPS 204)
validator_qtsp_token · RFC 3161 trusted-timestamp token, never NTP
2reviewerWho verified it?
reviewer_signature_input_hash (SHA-256)
reviewer_ed25519_signature
reviewer_mldsa65_signature (FIPS 204)
reviewer_qtsp_token · RFC 3161 trusted-timestamp token, never NTP
CbD

Compliance-by-Design

Which consent tiers and legal bases were in force?

dpa_version
1.0.0
baa_version
null, no HIPAA (residential)
tier2_consent_attestation
empty, no biometrics (BIPA)
tier3_notice_version
biometric_disclosure_basis
no_disclosure_occurred
3SealTamper-evident: commits to all prior signers
seal_input_hash (SHA-256)
pask_seal_ed25519
pask_seal_mldsa65 (FIPS 204)
pask_seal_qtsp_token · RFC 3161 trusted-timestamp token, never NTP

Once sealed, the receipt is tamper-evident: any change to any field invalidates all four signatures.

Verify this receipt →

Every receipt on this page was sealed with real keys on Pask’s own reference site, a staged deployment we built and operate. The cryptography is real. The customer, so far, is us.

Billy McKenzie and Rob Wilder, founders

03
Procurement · Compliance

Controls a CISO can buy against.

The receipt standard restated for procurement. Map each Engagement Receipt field to the controls it evidences, see who owns what across Pask, the Site Operator, and the OEM, and compile a re-verifiable evidence pack for any window. Greyed cells mean no coverage.
Validate these mappings against your own control framework with your auditor.
Control crosswalk

Every Engagement-Receipt field group, mapped to the named control(s) it is evidence for. Pick a framework; click any mapped cell to see the receipt field ↔ control detail. Greyed cells are no-coverage.

Wilder reference site · sample data
SOC 2 · Trust Services / Common Criteria8/8 field groups map to a control
Receipt field groupSOC 2 control(s)
§5.1header · prior_receipt_hash
CC7.2System monitoring / anomaly detection
§5.2identity · tee_identity
CC6.8Unauthorized/malicious software controls
§5.4approval · approving_party / approval_basis
CC6.1Logical access authorization
§5.5rats · attestation evidence
CC7.1Detection of configuration changes
§5.6execution · executing_agents / outcome_state
CC7.2System monitoring
§5.9-5.10validator + reviewer signatures
CC7.3Evaluation of security events
§5.11seal · pask_seal signatures
CC7.2System monitoring
compliancecompliance · consent / disclosure basis
P4.0Privacy: use, retention & disposal

Swipe the table for the mapped controls →

Control identifiers are indicative and should be validated against your own control framework with your auditor. A receipt field is evidence toward a control, not an attestation of compliance by itself.

Shared-responsibility matrix

An AWS-style split of who owns what across the three parties on a Pask site. Filled dots mark ownership; a shared row means the duty is split, not delegated.

Illustrative · sample data
PaskSite OperatorOEM

Attestation & evidence generation

Pask

Pask produces the signed Engagement Receipts, seals, and the offline verifier. This is the part Pask owns end-to-end.

Consent capture & disclosure basis

Site OperatorPask

Operator obtains and holds consent (BIPA §15(b), tenant notices); Pask records the disclosure basis on each receipt but does not gather consent for you.

Physical safety of the robot

OEMSite Operator

OEM certifies the device's safety envelope (E-stop, motion bounds); operator controls the physical site conditions it runs in.

Data retention & disposal

PaskSite Operator

Pask enforces appliance-only handling and no vendor-cloud sync; operator sets the retention schedule and owns lawful disposal.

Incident response

Site OperatorPaskOEM

Operator runs the response; Pask supplies the tamper-evident timeline; OEM handles device-level faults and firmware advisories.

Regulatory filing & liability

Site Operator

The operator files with regulators and carries the legal duty. Pask supplies evidence but is not the accountable filer.

The accountable filer, the consent-holder, and the party liable to regulators remain the Site Operator. Pask makes that party’s evidence portable and re-verifiable.

Evidence-pack export

Compile the Charter in force, active Mesh Contracts, the receipts in range, and the offline verifier reference into one portable JSON: assembled entirely in your browser, no network call. Compile the pack once; any reviewer re-verifies it offline, independently · no fieldwork request back to Pask.

Wilder reference site · sample data

The pack bundles sample evidence from the Wilder reference site. The bundle structure and the offline re-verification workflow are spec-true, so any reviewer reproduces the same verdict on their own machine.

Biometrics & BIPA

The Wilder reference site captures no biometrics, so there is no Illinois BIPA exposure on it by construction. On a site that does capture biometrics, the receipt carries the disclosure basis and the tiered consent attestation as its own fields, which is exactly what the crosswalk above maps. The default posture is no biometric capture; enabling it is a policy decision recorded in the Charter, not a silent default.

Durability & licensingOpen source · AGPLv3

The offline verifier is the first artifact published under AGPLv3: downloadable and readable today. The same license governs the reference implementation, so self-hosting and forking it are yours by right, never our permission, if the roadmap ever moves against you. A commercial license is available for procurement policies that exclude AGPL.

Audit trail

The signature verifies without calling the issuer: no Wilder and no hyperscaler in your audit trail. The document-signature standard is PAdES-LTV, an open long-term-validation signature standard.

04
Where humans touch Pask

Never per action. Once per engagement.

No human sits in a robot’s motion loop: Pask issues no movement commands and cannot interrupt one. What Pask holds is the engagement boundary: one plan-level approval, recorded as the first of four signatures on the Engagement Receipt. Four touchpoints. None mid-flight.
The pattern Pask rejects

A human clicking approve or deny on each robot action. That model concentrates risk on one operator and makes a fleet only as fast as the slowest human in the loop. Pask puts human judgment at the plan level, where it matters, and keeps people out of the motion loop, where waiting on a person is the failure mode.

Four touchpoints
01At deployment

The Site Charter

The accountable parties sign the Site Charter (minimum three signers: role, signatory, signature) covering where robots may work, when, and doing what. Every Charter carries a required expiration date; none is open-ended. Closer to a lease agreement than a permission slip.

02At the engagement boundary

One approval per plan

The plan is committed by hash before anything moves, and signer 0 on the receipt is the approving party, citing the Charter section and site policy it runs under. Per-engagement approval is the spec default; the approver can be a human signature, a delegated rule, or both. Plan-level, and it takes seconds. A plan the Gate refuses never becomes an engagement and produces no receipt.

03At exception time

Backstops, not dependencies

Every receipt records an outcome_state: completed, partial, or aborted (compliance profiles extend the set). A human gets paged when a record cannot be written, when an exception boundary is crossed (an override, a safety stop, a degraded sensor, a disputed outcome), or when a downstream system rejects a record. The design target is zero routine touches between approval and audit.

04At audit time

Retrospective, never gating

When an insurer, a regulator, a site owner, or a court asks “prove robot X did Y at time Z,” a human reads the chain. The carrier reads from the site’s chain directly. Records flow into the work-order or claim system you already run through an adapter stamped WRITE_ONLY; the operations layer never writes back into the evidence.

What the protocol holds
  • One approval, four signatures.0Approval1validator2reviewer3Seal

    Signer 0 is the authorization record itself: who approved the engagement and under which Charter section. That is what an auditor needs to route a question.

  • Write-only outward.

    Sealed records flow one way into downstream systems and return an acknowledgement digest. Reading and verifying the chain requires no Pask software.

  • Witnessed as it happens.

    A per-engagement nonce is minted at plan time, the on-site appliance observes the engagement window, and the seal lands at the end. Tamper-evident from that moment on.

The scaling story
  • No per-action human anywhere in the design. A robot action inside an approved engagement never waits on a person.
  • The human cost curve is set by policy, not robot count. Per-engagement approval is the default; where the site’s policy allows, a delegated rule stands in for the signature. Adding robots adds receipts, not headcount.
  • Failure is visible. If Pask goes down, robots keep running: motion control never depended on it. What stops is new engagement planning and gating, and the outage is visible in the chain rather than silent.

Pask does not adjudicate liability. It makes liability legible.

05
Reference

Glossary

Every acronym and spec term the site uses, in plain English. This is the one place the full list lives; the same definitions surface as hover tooltips wherever a term appears.
Pask
The signed system of record for automated work on a multi-vendor site. It watches authorized activity and produces one signed record per engagement: a witness, not a vault.
Site Charter
The signed founding document for a site: who and where it is, what its policies allow, and when its authority expires. Every other Pask artifact derives from it.
Mesh Contract
A signed contract each participant (robot, sensor, service, or person) publishes to be admitted to a site: declaring up front what it is and what it is allowed to do.
Conversation Template
A pre-approved script for a kind of engagement: which actor may do what, under which policy, and what approval it needs before it runs.
Engagement
A bounded, approved unit of work, which may contain many robot actions. One receipt per engagement.
Engagement Receipt
One sealed, signed record of a single engagement: who acted, what happened, when, and under whose approval. It verifies on its own, without calling Pask.
validator
A signer role in the receipt chain: the participant that attests the engagement stayed within site policy before the record is sealed.
reviewer
A signer role in the receipt chain: the independent participant that countersigns a sealed receipt so a third party can trust it later.
Approval
The first signer (0) on a receipt: the accountable party who authorized the engagement, citing the Charter section and policy it runs under.
Seal
The final signer (3) on a receipt: the Pask appliance commits to the finished record's fingerprint, closing it forever. Any later change breaks the seal.
teachback
A conformance check where the participant demonstrates its declared behavior back to the site: proving the contract describes the real device, not just paperwork.
CL-1Conformance Level 1
The lowest Mesh Contract grade: the contract is schema-valid, well-formed and complete, but not yet independently exercised.
CL-2Conformance Level 2
A middle Mesh Contract grade: the participant backs its declared behavior with signed telemetry, checked against its actual signals, not just paperwork.
CL-3Conformance Level 3
The highest Mesh Contract grade: the participant's evidence is bound to a hardware TEE attestation (RATS), so its identity and measurement are proven, not just asserted.
COSECBOR Object Signing and Encryption
An IETF standard (RFC 9052) for compact, signed data objects. Pask uses it as the envelope format for a sealed receipt.
SCITTSupply Chain Integrity, Transparency and Trust
The IETF standard for signed, independently-verifiable transparency receipts (architecture RFC 9943, receipts RFC 9942, 2026). Pask is designed to adopt it rather than invent a proprietary receipt format.
CBORConcise Binary Object Representation
A compact binary data format (RFC 8949): like JSON, but smaller and unambiguous, so a hash of it is stable.
Ed25519
A fast, widely-trusted elliptic-curve digital signature scheme (RFC 8032). One of the two signatures on a Pask receipt.
ML-DSA-65Module-Lattice Digital Signature Algorithm
A post-quantum digital signature standardized by NIST (FIPS 204, based on 'Dilithium'). Added alongside Ed25519 so receipts survive future quantum attacks.
FIPS 204
The NIST standard that defines ML-DSA, the post-quantum signature scheme Pask pairs with Ed25519.
SHA-256
A cryptographic hash function that turns any data into a fixed fingerprint. Change one byte and the fingerprint changes. That is how tampering is caught.
RFC 3161
The internet Time-Stamp Protocol: a trusted authority signs 'this data existed at this time,' so a receipt's timestamp can be proven independently.
canonicalization
Serializing data into one agreed byte order (keys sorted, no ambiguity) so that everyone who hashes the same record computes the same fingerprint.
proposed_plan_hash
The SHA-256 fingerprint of the proposed plan that the Approval signer commits to. The plan itself is committed by hash, never embedded in the receipt.
seal_input_hash
The SHA-256 fingerprint of the receipt body that the Seal signer commits to. Recompute it yourself from the receipt: if it doesn't match, the record was altered.
prior_receipt_hash
Each receipt carries the fingerprint of the receipt before it, chaining them in order. Remove or alter one and every later link stops matching.
nil hash
All zeros: the placeholder a site's very first (genesis) receipt carries in prior_receipt_hash, because there is nothing before it to chain to.
alg_suite
The receipt field naming which signature algorithms sealed it. Suite 2 = Ed25519 plus post-quantum ML-DSA-65, side by side.
nonce
A fresh random number used exactly once in a challenge, so a proof can't be replayed from an earlier session.
attestation
Hardware-backed proof of what code is running and where: the appliance demonstrating, cryptographically, that it is the real thing in a genuine secure environment.
RATSRemote ATtestation procedureS
An IETF architecture (RFC 9334) for proving, remotely, that a system is running trustworthy software on trustworthy hardware.
TEETrusted Execution Environment
A hardware-isolated part of a processor where code and data are protected even from the operating system: where the Pask appliance guards its keys.
SEV-SNPSecure Encrypted Virtualization, Secure Nested Paging
A hardware technology for a Trusted Execution Environment. It encrypts and isolates a workload's memory and can attest that isolation held.
VCVerifiable Credential
A W3C standard for a tamper-evident digital credential whose issuer and claims can be checked without contacting the issuer.
DIDDecentralized Identifier
A W3C standard for an identifier a subject controls itself, resolvable without a central registry, used to name participants durably.
PAdES-LTVPDF Advanced Electronic Signatures, Long-Term Validation
A European standard (ETSI EN 319 142) for PDF signatures that stay verifiable for years, even after certificates expire.
QTSPQualified Trust Service Provider
Under EU eIDAS, an accredited provider whose electronic signatures and timestamps carry legal weight across the EU.
eIDASelectronic IDentification, Authentication and trust Services
The EU regulation governing electronic identity, signatures, and timestamps: the legal frame that makes a Qualified timestamp binding.
BIPABiometric Information Privacy Act
Illinois' biometric-privacy law (740 ILCS 14). On sites that capture no biometrics there is no BIPA exposure by construction.
FRE 902(13)/(14)Federal Rules of Evidence 902(13) and 902(14)
The federal rules that let a machine-generated record, or data verified by a digital process, be self-authenticating with a certification, so it can come in without live witness testimony. A Pask receipt is built to support this; treatment is a call for your own counsel.
AGPLv3GNU Affero General Public License v3
An open-source license: run and self-host freely: its share-alike terms attach only if you offer a modified Pask to third parties as a network service.
EU AI Act
The EU's regulation on AI systems. Its Annex III lists 'high-risk' uses that carry record-keeping duties a Pask receipt helps satisfy.
AMRAutonomous Mobile Robot
A robot that navigates a site on its own: a common participant on the multi-vendor floors Pask coordinates.
3PLThird-Party Logistics
A firm a site outsources warehousing and fulfillment to: one candidate to operate the Pask layer on a site's behalf.
OEMOriginal Equipment Manufacturer
The company that builds a robot or device: the vendor whose fleet joins a site under a Mesh Contract.
ROS 2Robot Operating System 2
The open robot middleware standard widely used across modern robotics: the plumbing a vendor's own stack often speaks internally.
OPC UAOpen Platform Communications Unified Architecture
The standard industrial devices (sensors, PLCs, fixed equipment) use to publish their data: how non-robot participants speak.
Spoliation
Losing or destroying evidence you should have preserved once a lawsuit is foreseeable. Under Federal Rule of Civil Procedure 37(e), a US court can sanction a party for lost electronic records.
Rule 37(e)Federal Rule of Civil Procedure 37(e)
The US federal rule on lost electronic evidence: if records that should have been preserved for litigation are lost, courts can impose sanctions, up to an adverse-inference instruction.
ESIElectronically Stored Information
The electronic records (logs, sensor data, video) that US civil litigation runs on. Robot ESI is volatile: it can be overwritten within hours of an incident.
FNOLFirst Notice of Loss
The first report to an insurer that a loss happened: the moment a claim file opens. A sealed receipt means the evidence arrives with the FNOL instead of being reconstructed later.
Subrogation
After paying a claim, the insurer's right to recover from whoever actually caused the loss. On a multi-vendor site that requires proving whose robot or action did it.
General Duty Clause
OSHA's catch-all: employers must keep the workplace free of recognized hazards. With no robot-specific OSHA standard, robot incidents are cited under this and existing machine rules.
LOTOLockout/Tagout (29 CFR 1910.147)
The OSHA standard for de-energizing machines before people work on them: one of the existing rules OSHA applies to robot cells today.
MGAManaging General Agent
An insurance agency with delegated authority from a carrier to underwrite, price, and bind policies in a specialty class. MGAs are the standard vehicle for launching classes the admitted market does not write yet.
GLGeneral Liability
The broad commercial policy covering third-party injury and property damage. Robotics exposure usually rides on GL or property class codes today because no dedicated robotics class exists.
NAICNational Association of Insurance Commissioners
The standard-setting body for US state insurance regulators. Its Managing General Agents Act, adopted by most states, is the regulatory scaffolding MGAs operate under.
LAELoss-Adjustment Expense
What it costs a carrier to investigate and settle a claim, separate from the loss itself. Reconstruction-heavy claims push LAE up and eat a program's margin.
Cedent
The insurer that passes (cedes) part of its risk to a reinsurer. A cedent that can prove the shape of its book gets better treaty terms.
Treaty
A standing reinsurance agreement covering a whole book of policies rather than one risk at a time. Treaty underwriters price the book's shape, so provable exposure matters.
STHSigned Tree Head
The transparency log's signed summary: the Merkle root, tree size, and a signature over both. Verifying a receipt's inclusion proof against the STH proves the log committed to it.
Surplus lines
The market for risks the standard admitted market will not write, served by specialty carriers under lighter rate-and-form regulation. New classes typically start here.
Tamper-evident
Any change after sealing is detectable: edit a field and the signatures and hashes stop verifying. Not unchangeable; changes cannot hide.
outcome_state
The receipt field recording how the engagement ended: completed, partial, or aborted, with compliance profiles adding extension values.
WRITE_ONLY
The adapter mode: Pask writes sealed records into the ops or claims systems you already run and reads nothing back. A property of the outbound adapter, not of receipts.
NIST AI RMFNIST AI Risk Management Framework
The US reference framework for managing AI risk (voluntary). Its Govern function expects AI incidents and decisions to be recorded and traceable: show, not just say.