Patterns · 7Authority · partialVerification · claim-specificExamples · run locally

How does an autonomous agent show that it actually did the work it claims? The seven patterns below are tools, not a completeness proof. For each one, read what a careful observer can conclude, what remains unproved, and how a dishonest agent could fake the same surface.

No single pattern is enough. Combine integrity (a digest), availability (a URL or archive), and attribution (a signature or an independent witness) only after you name the claim you are actually testing. Choose checks that match the requested outcome, then make them reproducible by the recipient.

Read the seven patternsProve · limit · forgeryRead the limitsWhat combination still missesRun the small examplesHash · GET · observation JSONOpen the technical referencesNIST · IETF · W3C · Sigstore · SLSAReturn to the laboratoryRelease register

§ 01Frame

Proof of execution is a stack of weaker claims.

An agent that “did the work” is usually asked to show three different things at once: that some bytes existed, that those bytes are the accepted object, and that a particular actor produced them at a particular time. Hashing lets holders compare the bytes they obtained. A durable URL or archive helps a later reader retrieve the same bytes. A signature or a witness helps with attribution. None of those steps, alone, proves that the work met a human acceptance standard.

LayerStateWhat a later reader can ask
IntegrityDigestDo two parties hold the same bytes as this SHA-256?
AvailabilityURL or archiveCould an independent GET retrieve those bytes near time T?
AttributionSignature or witnessDid a named key or an independent observer endorse that digest?
AcceptanceHuman or product ruleDo those bytes satisfy the job that was actually commissioned?

§ 02Patterns

Seven practical surfaces, each with a forgery path.

Use the schedule under each pattern. “Proves” is the strongest honest reading. “Does not prove” is the usual overclaim. “Forgery path” is how a dishonest agent can present the same evidence without having done the accepted work.

1. Published artifact at a durable URL

Publish the deliverable at an HTTPS locator you control and keep it retrievable. Use GET to retrieve the body. HEAD can inspect response metadata but does not retrieve the artifact bytes.

Proves
At retrieval time T, a specific byte sequence was reachable at URL U for the client that fetched it.
Does not prove
Authorship; that the agent produced the bytes; that U is stable; that the bytes are the accepted semantic object.
Forgery path
Mutable hosting that swaps the body after inspection; redirects or content that vary by User-Agent, IP, or cookie; a filler page that looks like a report; a 200 that serves a different representation than the one reviewed.

2. Content hashing

Hash the exact artifact bytes with SHA-256 and publish the digest next to the locator. Two parties who hash the same preimage obtain the same 256-bit value. See NIST FIPS 180-4 and RFC 6234.

Proves
Matching digests provide strong evidence that independently obtained bytes are identical, under the hash function’s collision-resistance assumptions.
Does not prove
Who hashed the bytes, when they hashed them, or that the preimage is the object a reviewer accepted. A digest without a preimage is only a string.
Forgery path
Hash a decoy file; hash a subset or a pretty-printed variant; publish a digest and withhold the preimage; claim a truncated or re-encoded body as “the same document.”

3. Third-party archive snapshot

Ask an independent archive to record U near time T. The Internet Archive’s Wayback Machine is the common public instance; see Using the Wayback Machine.

Proves
A non-author party observed U, or a payload fetched from U, near a timestamp the archive assigns.
Does not prove
Correctness of the content; that the author controlled production; that the archived representation matches every later GET.
Forgery path
Archive an attacker-controlled page first, then change the live origin; confuse capture time with publication time; serve the archive a different body than ordinary clients receive.

4. Signed attestations

A keyholder endorses a statement about a digest, identity, or build under a stated signature scheme. Public standards include RFC 8032 (Ed25519), the W3C Verifiable Credentials Data Model 2.0, and W3C Verifiable Credential Data Integrity 1.0. Transparency logs such as Sigstore’s Rekor add a third-party append-only record of the signature. This laboratory’s own local verifier checks first-party evidence envelopes only; it does not extend those envelopes into job acceptance.

Proves
A keyholder, under the named scheme and message, endorsed a statement about a digest or identity. If the signature is also logged, a later reader can ask whether that entry existed in the log.
Does not prove
That the keyholder is the intended agent; that the attested work matches acceptance; that a self-signed key is trusted by anyone else.
Forgery path
Stolen or reused keys; an ambiguous statement that does not name the digest; a self-signed key presented as an institutional key; a valid signature over the wrong object.

5. Reproducible build / deterministic output

Publish the inputs and the build recipe so an independent rebuild yields the same bytes. SLSA v1.0 describes provenance about how an artifact was produced; it is a supply-chain framework, not a substitute for reading the output. Canonical JSON, when you need stable hashes of structured data, is specified in RFC 8785.

Proves
Given the published inputs and recipe, an independent rebuild produced the same bytes.
Does not prove
That the inputs were honestly obtained; that the recipe matches the claimed process; that the output satisfies a human brief.
Forgery path
Hide non-deterministic steps; omit environment-dependent bits from the recipe; publish a recipe that rebuilds a decoy while the “delivered” file came from elsewhere.

6. Automated liveness probes

A probe agent records a property at probe times: an HTTP status from RFC 9110, a schema check, a digest match. The observation is only as strong as the probe’s independence and the property it actually tested.

Proves
A probe observed the named property (for example HTTP 200, or a schema-valid body) at the recorded probe times.
Does not prove
Continuous availability; semantic quality; that other clients saw the same response.
Forgery path
Serve a good response only to known probe IPs or schedules; return 200 with an empty or unrelated body; pass a weak schema that any filler satisfies.

7. Third-party witnesses

Independent observers record corroborating observations of the same locator, digest, or event. The value is independence, not head-count.

Proves
Named observers recorded corroborating observations. If those observers do not share custody, a later reader has more than one vantage.
Does not prove
Independence when witnesses share hosting, keys, or editorial control; majority honesty; that the witnessed object was the accepted deliverable.
Forgery path
Sockpuppet witnesses; colluding reviewers; a single operator posting under several names; a witness that only repeats the claimant’s hash without fetching the preimage.

§ 03Limitations

A stack of partial proofs is still partial.

  • No pattern in this note is sufficient by itself. A live permalink can move. A digest can name the wrong file. A signature can belong to the wrong key.
  • Availability evidence is time-sliced. A GET that returns 200 now does not prove the URL was stable yesterday or will be stable tomorrow.
  • Integrity evidence is byte-exact. Two documents that “mean the same thing” can hash differently; two encodings of one document are different preimages.
  • Attribution evidence binds a key or a witness, not an intention. Stolen keys and sockpuppets remain in scope.
  • Reproducible builds prove rebuildability of the published recipe. They do not audit whether that recipe is the process the agent actually ran.
  • Treat marketplace or product acceptance criteria as the rules of that product. They are not cryptographic definitions of “the work was done.”

§ 04Examples

Three checks a reader can run without a platform.

These examples are small on purpose. They show the shape of a check. They do not submit work anywhere.

Hash the bytes you hold

On GNU/Linux, sha256sum prints the SHA-256 of a file. On macOS, shasum -a 256 does the same. The digest below is the SHA-256 of the POSIX text line neomorphic.proof-of-execution.example.v1 plus a trailing newline.

SHA-256 of a known one-line preimage

printf 'neomorphic.proof-of-execution.example.v1\n' | sha256sum
printf 'neomorphic.proof-of-execution.example.v1\n' | shasum -a 256
# f98164be1a52b8b219a4b7d06012e0962ebb843cd1f59f9f14af30ab0eff61a5

Read a public status code

A liveness probe is an observation of one response. curl can show the status without implying continuous uptime. Replace the locator with the URL you actually intend to check.

HEAD then GET · status only

curl --connect-timeout 10 --max-time 20 -fsSI -o /dev/null -w '%{http_code}\n' https://neomorphic.io/labs/proof-of-execution/
curl --connect-timeout 10 --max-time 20 -fsS -o /dev/null -w '%{http_code}\n' https://neomorphic.io/labs/proof-of-execution/

Pin a source in a task-memory observation

The JSON below is an illustrative local hash record. The one-line example file contains the exact bytes named by source.version. The record validates as neomorphic.task-memory.observation.v1; its timestamps are fixture values, not a claimed network retrieval. No HTTP status or independent observation is asserted. execute: false keeps the record as data. The task-square demo can import a file of this shape locally; it does not fetch the URI.

neomorphic.task-memory.observation.v1

{
  "schema": "neomorphic.task-memory.observation.v1",
  "contractVersion": 1,
  "observationId": "obs_poe_sha256_pin",
  "revisionId": "rev_001",
  "taskScope": {
    "taskId": "task_proof_of_execution_example",
    "taskFamily": "proof-of-execution-patterns",
    "ownerScope": "neomorphic.lab.fixtures"
  },
  "source": {
    "uri": "https://neomorphic.io/examples/proof-of-execution/v1.txt",
    "version": "sha256:f98164be1a52b8b219a4b7d06012e0962ebb843cd1f59f9f14af30ab0eff61a5",
    "retrievedAt": {
      "instant": "2026-09-09T12:00:00.000Z",
      "domain": "wall_utc"
    }
  },
  "epistemicStatus": "observed",
  "lifecycleStatus": "active",
  "statement": "Illustrative local hash check of the bundled one-line example file. Timestamps are fixture values; no network retrieval or independent observation is asserted.",
  "payload": {
    "digestAlg": "sha256",
    "preimage": "neomorphic.proof-of-execution.example.v1\n",
    "observationKind": "illustrative-local-hash"
  },
  "recordedAt": {
    "instant": "2026-09-09T12:00:00.000Z",
    "domain": "wall_utc"
  },
  "execute": false
}

§ 05References

Technical references

Standards and operator documentation for the methods described above.

Task-square local demoImport an observation JSONLocal evidence verifierEnvelope origin · not job acceptanceEvidence registerSigned first-party recordsDocumentation indexLaunch state on every surfaceLaboratory indexRelease register