A thought for today
01 / Selected work

Explore the work.

A closer look at the ideas, decisions, and development behind my projects.

06 / BEYOND THE PUBLIC DEMOS

Some ideas start with a conversation.

Additional prototypes may be discussed individually, with details shared where appropriate.

Start a conversation ↗
Selected work / 01

Problem

A database can remember history. What makes that history trustworthy?

Version tracking shows how a record changed. But what happens when someone with privileged access can change the record—and rewrite its history too?

Cryptographic fingerprints link records together, making alterations detectable. Comparing them with checkpoints preserved outside the database helps expose even a rewritten history that looks internally consistent.

SealRight

Cryptographically verifiable history for ideas and contributions.

SealRight applies this approach to recording who submitted what and when, helping make changes to submission history detectable. It is built on Postgres and Supabase, with independent verification in Google Cloud.

My contribution

I designed and built the system end to end with Claude as my AI pair-programmer. That covers the ledger schema and its guards in Postgres, the hash chain and Merkle-tree batching, a scheduled anchor-writer that publishes each batch to a git repository and an RFC 3161 timestamp authority, and an hourly independent verifier on Google Cloud that holds read-only access and keeps its own insert-only mirror.

Engineering decision

Database rules alone cannot stop an administrator, who can switch them off. So I aimed for tamper-evident rather than tamper-proof. Checkpoints go to witnesses the operator cannot rewrite, and a separate program with its own read-only identity recomputes everything and believes nothing it has not checked. I did not use a blockchain, because there are no mutually distrusting parties that need consensus.

Current status

Working prototype, running on a schedule: batches close every 15 minutes, anchors are published, and the verifier runs hourly. Still open: a second independent anchor (OpenTimestamps), signature verification, and alert routing.

Evidence

The ledger maths were reimplemented separately in Python and matched the database functions exactly on an entry hash, an idea hash, a Merkle root and a checkpoint. The verifier also caught real faults in my own build, such as a batching job that had never been scheduled, and the fixes are documented.

Architecture diagram and screenshots of a verifier run will be added here.
Selected work / 03

MeritMap

A selection workbench that helps ideas move from submission to a reasoned decision.

Problem

Collecting ideas is only the beginning. Reviewers need a consistent way to assess proposals, find related work, explain their choices, and limit the influence of a submitter’s identity.

Review workflow

Intake queue → compare similar ideas → blind scorecard → shortlist → decision and feedback. Administrators manage reviewers, criteria, selection cycles, and leadership access. Leadership can view programme metrics and shortlists.

Engineering decisions

MeritMap keeps review opinions separate from SealRight’s factual ledger. Decisions and early identity reveals are recorded through SealRight’s own functions. An early reveal requires a reason, while other reviewers’ scores are withheld until a reviewer has submitted their own.

The Claude AI assist surfaces similar ideas, relevant past decisions, and a neutral summary. It receives no author identities and does not score, rank, or decide. Reviewers accept or dismiss its suggestions.

Architecture

HTML and JavaScript pages connect to a serverless API backed by Postgres functions. Country-specific SealRight sources feed a shared review layer, while private idea text stays in its source schema and reviewer rights remain country-specific.

Current status

Prototype implementation includes reviewer, leadership, and administration pages, an AI-assist integration, and database rollback test scripts. This portfolio review inspected source code; a live deployment and end-to-end behaviour have not been verified.

Selected work / 04

SealRight Anchor

A Python service that publishes SealRight batch checkpoints to GitHub and obtains RFC 3161 timestamp tokens, recording each anchor through narrowly scoped database functions.

Problem

A checkpoint stored beside the records it protects can be rewritten with them. Publishing it elsewhere gives an independent verifier evidence to compare.

How it works

Each run finds closed batches missing an anchor, publishes checkpoint files or timestamp tokens, tags the corresponding commits, and records the references. Git and timestamp anchoring run independently so one method can catch up without blocking the other.

Engineering decisions

The writer is separate from the read-only verifier and uses its own restricted database role and repository-scoped write credential. Corrections append a new anchor record rather than editing earlier claims.

Current status

Source includes scheduled-job deployment support, handling for concurrent runs, and an explicit correction path. Runtime scheduling and timestamp-service availability were not checked in this portfolio review.

Selected work / 05

SealRight Verifier

A Python verifier that recomputes ledger and batch hashes, checks outside anchors, and compares saved state to detect changed references or a shrinking ledger.

Problem

An internally consistent history may still have been rewritten. Independent checks need external evidence and a memory of what was previously observed.

How it works

The verifier checks the entry chain, batch shape and Merkle roots, external anchor proofs, ledger head progression, and unbatched-entry age. Reports include counts and findings; alerts and heartbeat signals distinguish a completed check from a job that stopped running.

Engineering decisions

Read-only source access keeps verification separate from publishing. An optional Cloud SQL mirror preserves observed entries and batches for later comparison, while saved Git commit references help detect retargeted anchors.

Current status

The source includes Google Cloud deployment infrastructure and canonical-encoding and Merkle tests. Signature verification is not implemented; idea-content verification is not wired into the check runner, and guard/grant inspection is skipped where the reader lacks visibility. Live operation was not checked in this portfolio review.