Pask is a witness
for robots at work.
When a robot's work is questioned, someone outside the vendor should be able to check the record. Pask is being built for that: a signed account of a robot's job, held at the site.
Explore the full reference site at pask-witness.com
Illustrative data · Local fingerprint check
DEMO-0001
Not checkedEdit either blue field to compare its SHA-256 fingerprint with the original. Spaces count too.
Original fingerprintbc5414008194068f025aa21edb9f96a91f4d576762a39cf4dcd33da64f67cc31
Current fingerprintNot calculated
This checks sample text only. It is not a digital signature, hardware check, or conforming Pask receipt. Your edits stay in this browser.
The fingerprint check is unavailable in this browser. You can still explore the reference demo.
A record the site can keep.
Pask's design puts a witness at the site, separate from the robot. Its receipt describes the recorded job, the actor and site, the operating limits, and the evidence tied to that account.
For a site owner
Keep an account alongside the work order, rather than relying only on the robot vendor's dashboard. The goal is a record that another party can examine.
For a carrier
A signed account can support a claim investigation. It does not replace the full claim file or decide coverage, liability, or whether the work was correct.
From site rules to a checkable record.
These stages describe the design, not a claim that the complete workflow is deployed. An engagement is a bounded job under stated operating limits.
Set the site rules.
Describe the site, who may act there, and the limits on the work.
Identify the participants.
Record the robot or other actor and its responsible operator.
Establish the job's scope.
Connect the engagement to the site's operating permissions and boundaries.
Sign and register the account.
The profile requires a signed statement and registration with a Transparency Service.
Let another party check it.
Offline checks need the saved record and proofs, plus verification keys and trust information the recipient accepts.
A checkable account still has limits.
A signature can help show that signed content has not changed. A valid registration proof shows inclusion in a particular log. Neither proves every event was captured or that the reported work happened as described.
Pask is intended to witness work alongside robot operations. It does not certify safety, decide liability, or establish regulatory compliance. Its full specification guide explains the trust assumptions and current limits.
Open to inspection.
The -04 draft, dated September 14, 2026, defines wilder.pser/0.6. It is an individual submission to the Internet Engineering Task Force (IETF), not an adopted IETF standard or endorsement.
The profile builds on SCITT, the architecture for signed statements and transparency receipts in RFC 9943 and RFC 9942. It uses a COSE signed-data envelope. The earlier wilder.pser/0.5 retains its own requirements.
The public Rust reference code has a component-specific license split:
- Apache-2.0
- Interoperability tools:
pask-wire,pask-attest, andpask-wire-cli. - AGPL-3.0-only
- Deployment tools:
pask-site,pask-adapter, andpask-ts-client.
Use is subject to each component's license. A commercial licensing path is available for the AGPL components by separate written agreement. See the full license map.
These examples cover selected checks, not complete profile certification. The website's browser demo is separate from the Rust tools.
Bring a real site question.
Tell us about a robot job at your site and the record you'd need if someone questioned the work.