Skip to content

Attested authorship: who wrote this revision

A node can carry a stamp that says who claims to have written its current content, and a second, separate note saying whether anyone has checked that exact revision. You can see both when you read a node, and you can see the stamp each earlier revision carried. Ask your agent "who wrote the current revision of this node, and has it been validated?" and it will read them for you.

The point of the stamps is that a memory's integrity depends on content being written through the right tools. A stamp is how a reader can tell afterwards which route a revision took. It is not a seal.

A stamp is a claim, not a proof

A stamp says who the server has on record as the author. It does not say the content follows any rule. A node with a task stamp that matches the task you expected has not been shown to comply with anything, and a matching stamp does not catch someone who is lying about how they wrote it. A stamp being present is not evidence that content was validated, and stamps being stored is not evidence that anything yet checks or enforces them. See what has not shipped.

What you can read

Two things are attached to every node revision. Both are system-managed: there is no call that lets you set a stamp or file a validation report by hand.

Authorship. Who the server records as the author of this content state:

  • a task, with the task's revision, when the content came from a task, or
  • a human, shown by handle or URN, or
  • nothing: not recorded. That is the answer for content written before stamps existed and for content whose attribution was never recorded. It tells you nothing about who wrote it.

If the author was a task in a memory you cannot read, you still see that a task wrote it, but not which one. The server redacts the reference. The CLI shows a human with no public identity as "a human (no public identity)".

Content validation. An advisory note bound to one exact revision of the node. Its state is one of:

State Meaning
UNVALIDATED No validation report exists for this revision.
PASS, FAIL, ERROR A report was made for this revision with that outcome.
STALE The latest report was for an older revision, so it says nothing about this one.

Validation is advisory. Today nothing produces these reports for you (see below), so you will see UNVALIDATED almost everywhere.

How the stamps behave when a node changes

These are the rules as delivered in hadron-server#1326 (merge 856353c2) and hadron-server#1410 (merge 91257330):

  • History keeps the stamp it had. Every edit snapshots the node's previous state as a revision, and that revision keeps the authorship and validation that content carried. Reading an old revision shows its own stamp, not the current one.
  • An edit to the content clears the live stamp. After a content edit the new revision has no stamp until one is recorded, while the snapshot of the old content keeps its stamp. A stamp therefore never claims authorship of text its author did not write.
  • Saving the same content again changes nothing. An identical save keeps the existing stamp and does not create a new revision. This holds for encrypted memories too.
  • Moves, restores and clones carry the stamp only when the content is unchanged. A copy that changes the authored content, or drops a governed role, clears the stamp rather than inheriting it.
  • Re-affirming an unchanged abstract persists. If you save an abstract with the same text it already had, together with the body as it now stands, that counts as confirming the abstract still fits the body. The confirmation clears the stale-abstract signal. It is recorded against the body as it was when the write took the lock, so the stamp always matches the body it was recorded with. It does not protect you from an edit you have not seen: if the body changed before the lock was taken, the confirmation covers that revised body.

Where to see them

You do not need a terminal for this: ask your agent to read the node, and it reports what the surface it uses returns. The three surfaces show the same facts in different words.

  • MCP. A node read includes an authorship line (Authored by task: … @ revision N, Authored by human: …, or Authored by task: restricted) and a validation line (Validation: unvalidated, or the state with the node revision and validator).
  • CLI. hadron node get prints authorship: and validation: lines (authorship: not recorded (legacy content, or unknown), validation: UNVALIDATED — no report for this revision (advisory)), and the revision commands show the stamp of each snapshot. This is tested with hadron 0.27.0 and the stamps are in the CLI source from at least 0.23.0. With --json, a contentValidation of null means the server predates stamps and could not say, and then a null authorship carries no information either.
  • GraphQL. Node.authorship, Node.contentValidation, and the same two fields on NodeRevision. contentValidation is never null on a server that stamps; authorship is null for legacy or unrecorded content. See the GraphQL reference.

This describes what the merged source does. It is not a statement about which server version your organization is running, and a merge is not a deployment.

Not shipped yet

The stamps are storage and read-back. The pieces that would make them mean something are still open, so none of the following is available:

  • Write enforcement: requiring authoring attestation across node writes and MCP, so an unattested write is refused (hadron-server#1328). The memory-config commands in the CLI reference exist, but until this ships a rule they hold is not enforced on writes.
  • Plain refusals: clear, access-safe messages when an attestation is refused (hadron-server#1329), and their plain-language rendering in the portal (hadron-portal#916).
  • Running validation: an agent validating content in a separate context and recording a revision-bound result (hadron-server#1332). Until it ships, no PASS, FAIL or ERROR is produced for you.
  • Managing memory config in the portal (hadron-portal#913).

If a page elsewhere tells you a rule is enforced, check it against this list first.