A Minimal Cryptographic Affidavit Process for Digital Artifacts

Purpose

This process creates a signed affidavit that cryptographically binds a SHA-256 hash of a digital artifact to a verifiable GPG identity, enabling independent verification of integrity and authorship without asserting factual truth.

This is useful for publishing essays, research notes, creative work, datasets, or any digital artifact where you want to demonstrate:

The file has not changed since a specific moment in time
A specific cryptographic identity controlled the signing key
Verification can occur independently, without contacting the signer

Threat Model (What This Does and Does Not Do)

This process proves:

File integrity (tamper detection)
Control of a specific GPG private key at signing time
A clear, auditable chain of verification

This process does NOT prove:

The truthfulness of the content
The authenticity of events depicted
That manipulation did not occur before hashing

This is an integrity and authorship signal, not a claim of objective truth.

Signing Process (Author / Publisher)

0) Preconditions

The content file is finalized
You already have a GPG key
You will not edit files once hashing begins

1) Capture Artifact Details (for the affidavit)

stat -f "%N
Size (bytes): %z
Permissions: %Sp
Owner: %Su
Group: %Sg
Created: %SB
Modified: %Sm
Inode: %i
Device: %d
" "<file_name>" > file_details.txt

This records filesystem-level metadata at the moment of signing.
The output will be embedded into the affidavit, then discarded.

2) Create `affidavit.txt`

vi affidavit.txt

Affidavit Template

------------------------------------------------------------
AFFIDAVIT OF DIGITAL CONTENT INTEGRITY (SHA-256 + GPG SIGNATURE)
------------------------------------------------------------

I, <Full Legal Name>, declare under penalty of perjury that:

1) I am the creator or lawful custodian of the digital file(s) referenced below.
2) On <YYYY-MM-DD> at approximately <HH:MM> (<Time Zone>), I computed SHA-256 hashes
   for the file(s) listed in this affidavit.
3) To the best of my knowledge, the file(s) referenced have not been altered since
   the hashes were computed. Any modification would result in a different SHA-256
   hash and cause verification to fail.
4) I am signing this statement using my GPG private key. The corresponding public
   key fingerprint is:

   <YOUR FULL KEY FINGERPRINT>

Referenced Files:
- <file_name>
- affidavit.txt
- hashes.sha256.txt (hash manifest)

Executed on: <YYYY-MM-DD>
Location: <City, State, Country>

Signature:
<Full Legal Name>
<Contact info optional>

------------------------------------------------------------
File Details (observed at time of signing)
------------------------------------------------------------

<PASTE file_details OUTPUT HERE>

------------------------------------------------------------

After pasting the file details, delete file_details.txt.

3) Create the Hash Manifest

Include both the artifact and the affidavit:

shasum -a 256 <file_name> affidavit.txt > hashes.sha256.txt

4) Sign the Affidavit (Detached Signature)

gpg --armor --detach-sign affidavit.txt

Produces:

affidavit.txt.asc

5) Sign the Hash Manifest (Detached Signature)

gpg --armor --detach-sign hashes.sha256.txt

Produces:

hashes.sha256.txt.asc

6) Export the Public Key

gpg --armor --export "user@email.com" > user-publickey.asc

Final Evidence Bundle

Distribute these files together:

<artifact_filename>
affidavit.txt
affidavit.txt.asc
hashes.sha256.txt
hashes.sha256.txt.asc
<signer>-publickey.asc

Verification requires only GPG and SHA-256 tools.

Verification Process (Independent Verifier)

0) Preconditions

You have received the full evidence bundle
The bundle contains:
<artifact_filename>
affidavit.txt
affidavit.txt.asc
hashes.sha256.txt
hashes.sha256.txt.asc
<signer>-publickey.asc
GPG and shasum are installed
You trust the public key source or can verify its fingerprint independently

1) Import the Signer’s Public Key

gpg --import <signer>-publickey.asc

(Optional but recommended)

gpg --fingerprint <signer-email-or-key-id>

Confirm the fingerprint matches an independently published reference.

2) Verify the Affidavit Signature

gpg --verify affidavit.txt.asc affidavit.txt

Expected output:

gpg: Good signature from "<Signer Name> <email>"

3) Verify the Hash Manifest Signature

gpg --verify hashes.sha256.txt.asc hashes.sha256.txt

Expected output:

gpg: Good signature from "<Signer Name> <email>"

4) Verify File Integrity

shasum -a 256 -c hashes.sha256.txt

Expected output:

<artifact_filename>: OK
affidavit.txt: OK

5) Manual Review

Open affidavit.txt and confirm:

Signer identity
Public key fingerprint
Listed files match the bundle
File details match the received artifact
Date, time, and location align with expectations

6) Interpretation Guidance

A successful verification confirms:

The files have not changed since hashing
The affidavit has not changed since signing
The signer controlled the private key used

It does not confirm:

Truthfulness of the content
Authenticity of depicted events
Absence of manipulation prior to hashing

Closing Note

This process is intentionally modest in scope.

It does not attempt to establish truth, only integrity, authorship, and verifiability.

In an environment increasingly shaped by synthetic media, these signals matter.
They are not sufficient on their own, but they are necessary.

Using the Socratic Method to Drive Better Sprint Outcomes

Sprint Retrospectives are vital for continuous improvement, but sometimes the conclusions drawn can feel abstract or lack a solid foundation. By integrating the formal steps of the Socratic Method (Elenchus) into your retrospectives, you can drive a deeper understanding of your team’s experiences and produce more grounded, effective concluding actions.

The goal is twofold: a better understanding of the team’s experience and the generation of concrete, reality-based improvement actions.Gathering Experiences: The Formalized Socratic Method

The Elenchus method, or the Socratic Method of questioning and refutation, provides a formalized five-step process for dissecting an experience until its root definition is clear:

Receive: Ask the team members to share their experience from the previous Sprint. The key here is to listen without judgment and capture what happened in the team’s own words.

Reflect: Paraphrase the experience back to the team. This step is crucial for mutual understanding. By echoing back the main ideas, you ensure that you, as the facilitator, have accurately grasped the core issue and that the team agrees on the narrative.

Refine: Once the core experience is established, ask for underlying assumptions and supporting evidence. This is where you move beyond surface-level observations to examine the foundational beliefs and data points surrounding the experience.

Restate: Paraphrase the experience again, but now incorporate the newly added details about the assumptions and evidence. This iteration adds depth and precision to the definition of the issue.

Repeat: Continue this cycle of receiving, reflecting, refining, and restating until the experience is clearly defined, understood by all, and no further assumptions or evidence can be uncovered.

Reality Check: Ensuring Empirical Results

While powerful, the Socratic Method has been criticized for potentially producing false conclusions¹ if the underlying premises are flawed or not verified. In a retrospective, we cannot afford to base our future actions on abstract or unverified “truths.”

To address this, an essential step must be added to anchor the process in reality: Check the experience definition against empirical evidence.

Before moving to concluding actions, take the time to verify the clearly defined experience against your Sprint data-metrics, logs, burndown charts, or any other hard evidence. This ensures that the understanding you’ve developed is not only clear but also based in the reality of your team’s performance.

Concluding Actions: The Outcome

The entire exercise is focused on developing one of two, or both, critical outcomes for your next Sprint:

An Actionable improvement plan for the next Sprint.

An improvement of the Definition of Done (DoD).

By clearly defining the root cause of an experience and validating it against empirical evidence, your concluding action will be well-defined, measurable, and firmly based in reality. This significantly increases the likelihood that your next Sprint will incorporate a meaningful and effective change.

Caveat

It is critical that the facilitator ensures a high degree of psychological safety when employing the Elenchus method. The nature of sustained questioning and refutation must be carefully managed to prevent the process from feeling like a personal confrontation, keeping the focus strictly on the team’s shared experience and underlying assumptions.²

Month: January 2026