Post
115
Silence Is Failure
Three-layer architecture, one rule underneath it: autonomy is only valid if the layer writes its own logs. Silence is a failure state, not a neutral one.
LAYER 1
Scheduler — GitHub Actions
Clock, audit trail, no state. Logs run-started / run-failed / run-skipped.
LAYER 2
Heart — Worker / server
Heartbeat, timeline, artifact validation, KV as source of truth. Logs heartbeat events, runtime ticks, artifact audit results.
LAYER 3
Observer — Phone / Termux
Manual ops, local verification, mirror logs.
That's why a cron job exists at all in the repo I've been writing about — it's Layer 2's proof that Layer 1 actually ran. Not a heartbeat for its own sake.
Yesterday's post ("no artifact → no claim → exit 1") got read closely enough that someone found a real operational risk in exactly this repo — a good example of the axiom cutting both ways.
Context: a signed December 2025 chain (5 commits) is my earliest provenance for the governance methodology behind all three layers. The repo went through a real remediation in August — git-filter-repo stripped a sensitive file from history after a security review. filter-repo rewrites refs, but it doesn't delete objects. They sit unreachable until GitHub runs garbage collection.
A reader (crypto-forensics background, not affiliated with me) pointed out the actual danger: my five signed commits and the thing I want GC to delete are unreachable for the exact same reason. Ask GitHub Support to expire unreachable objects, and it doesn't distinguish — it takes both. GitHub's own removal-sensitive-data process confirms this: no scoped purge, whole unreachable set at once.
Fix: git tag each of the five SHAs before filing the request. A tag makes an object reachable, reachable survives GC, unreachable doesn't. Five commands, and the order is the part that matters — tag first, purge second, not the other way around.
git tag provenance-2025-12-29-1 d26dd346f7
git tag provenance-2025-12-29-2 08c3c310ef
Three-layer architecture, one rule underneath it: autonomy is only valid if the layer writes its own logs. Silence is a failure state, not a neutral one.
LAYER 1
Scheduler — GitHub Actions
Clock, audit trail, no state. Logs run-started / run-failed / run-skipped.
LAYER 2
Heart — Worker / server
Heartbeat, timeline, artifact validation, KV as source of truth. Logs heartbeat events, runtime ticks, artifact audit results.
LAYER 3
Observer — Phone / Termux
Manual ops, local verification, mirror logs.
That's why a cron job exists at all in the repo I've been writing about — it's Layer 2's proof that Layer 1 actually ran. Not a heartbeat for its own sake.
Yesterday's post ("no artifact → no claim → exit 1") got read closely enough that someone found a real operational risk in exactly this repo — a good example of the axiom cutting both ways.
Context: a signed December 2025 chain (5 commits) is my earliest provenance for the governance methodology behind all three layers. The repo went through a real remediation in August — git-filter-repo stripped a sensitive file from history after a security review. filter-repo rewrites refs, but it doesn't delete objects. They sit unreachable until GitHub runs garbage collection.
A reader (crypto-forensics background, not affiliated with me) pointed out the actual danger: my five signed commits and the thing I want GC to delete are unreachable for the exact same reason. Ask GitHub Support to expire unreachable objects, and it doesn't distinguish — it takes both. GitHub's own removal-sensitive-data process confirms this: no scoped purge, whole unreachable set at once.
Fix: git tag each of the five SHAs before filing the request. A tag makes an object reachable, reachable survives GC, unreachable doesn't. Five commands, and the order is the part that matters — tag first, purge second, not the other way around.
git tag provenance-2025-12-29-1 d26dd346f7
git tag provenance-2025-12-29-2 08c3c310ef