DBEvidence-bound systems
Menu

Work index / evidence before volume

Two flagships, two focused field notes, and a bounded historical shelf.

The hierarchy is intentional. Full case studies are reserved for implemented systems with verified evidence; supporting notes and dated coursework stay visibly in their own lanes.

Primary lane / implemented and verified

Flagship systems

Each row states the problem, my role, the supported decision or result, and the methods before it asks you to open the full evidence narrative.

01

BurnLens reached a public, complete Phase Six portfolio release: v0.56.0-baseline-first-portfolio-release at commit e2e0b778; the later evidence snapshot is a741111d, four commits after the release.

BurnLens

Read BurnLens case study
ReleaseVerifySnapshot
Problem
BurnLens asks how one bounded experimental computer-vision-to-geospatial intelligence release can become understandable, inspectable, citable, and responsibly interpretable as a coherent whole.
Intended reviewer
It is an experimental portfolio project for technical and technical-adjacent reviewers, not an operational wildfire tool.
My role
Drew set the portfolio thesis, target audience, use boundaries, owner stop conditions, and publication direction, and owned the human decisions; Codex was assigned technical, product, and reliability direction within that owner-defined envelope.
Decision
When the story was fragmented across correct artifacts, the project chose one canonical reviewer entry point around them rather than rewriting them.
Result
BurnLens reached a public, complete Phase Six portfolio release: v0.56.0-baseline-first-portfolio-release at commit e2e0b778; the later evidence snapshot is a741111d, four commits after the release.
Boundary
BurnLens is experimental portfolio evidence, not official wildfire information, emergency guidance, or operational decision support.
02

Verified synthetic testbed with a public v0.0.20 release and zero real systems connected.

Runbook Sentinel

Read Runbook Sentinel case study
  1. Read
  2. Reason
  3. Propose
Authority break
  1. Approve
  2. Check
  3. Execute
Problem
Keep a retrieval-grounded synthetic incident agent bounded when evidence is incomplete, stale, conflicting, or hostile without giving prose or model output execution authority.
Intended reviewer
Software and reliability reviewers assessing a bounded control architecture before any real-infrastructure connection.
My role
Repository author and release owner for the pinned public checkpoint.
Decision
Retain deterministic control instead of the tested local-model candidate and permit synthetic mutation only after separate approval and policy checks.
Methods
  • Python 3.12+Runtime, evaluation harness, verifiers, API and bounded diagnostic-tool server, and packaging
  • SQLiteSynthetic state, proposals, approvals, idempotency, execution, and audit persistence
  • JSON records and chained event logsContracts, evaluation artifacts, traces, and evidence bindings
  • JSON-RPC over stdioDiagnostic and read-only tool surface with no approval or execution tool
  • Python zipappDependency-free release artifact with exact allowlist and hashes
  • Loopback HTTP and server-rendered HTMLLocal operator, API, and dashboard surfaces
Result
The pinned v0.0.20 synthetic release passed its exact deterministic gate and excluded the weaker local-model candidate.
Boundary
A released synthetic testbed with explicit infrastructure, identity, trace, security, and evaluation limits.

Supporting lane / unnumbered

Focused field notes

Useful, bounded work without a flagship costume: one reviewed interaction prototype and one public documentation artifact.

Reviewed prototype represented by a frozen public reviewer snapshot.

Quest Craft

Problem
Help an adult Game Master turn an unexpected player choice into several playable paths without revoking player agency.
For
An adult Game Master facilitating players ages 9 to 12; the adult retains final authority.
My role
Product and system designer and release owner directing AI-assisted implementation, evaluation, correction, and approval.
Authority
The model supplies bounded wording, software validates the exchange, and the Game Master may accept, revise, combine, or ignore the result.
Evaluation
A fixed release suite of 12 synthetic scenarios, three retained rows each, human-scored cells, local privacy rejections, and corrective reruns.
Result
The reviewer snapshot retains 36 rows: 33 model generations, three local privacy rejections, six failed or superseded attempts, and two behavior corrections.
Boundary
A bounded public reviewer snapshot, not the private canonical implementation or a general safety result.

Public reviewer snapshot only. No private stack or general child safety claim is established.

Read Quest Craft field note

Public documentation artifact at an exact frozen commit.

OpenClaw Showcase

Problem
Explain a private agent-workflow pattern publicly without disclosure drift or pretending to prove the runtime.
My role
Author and designer of the public documentation layer only.
Public decision boundary
Separate public, approval-gated, and private material so only a human decision can expand the public boundary.
Public artifact
Eight Markdown documents, nine conceptual diagrams, a five-stage workflow model, and one sanitized representative receipt.
Public formats
Markdown and Mermaid are the public documentation formats, not evidence of runtime technologies.
Result
A frozen, inspectable public documentation artifact with explicit disclosure boundaries.
Boundary
The route documents a public workflow model and cannot establish anything about the excluded runtime's quality or capability.

Public documentation artifact only. The private runtime was not inspected or evaluated; no runtime capability, intended user, or failure dividend is established.

Read OpenClaw Showcase field note

Archive lane / dated and link-only

Historical reading shelf

These artifacts show earlier study and writing, not current engineering readiness. Dates, sources, and present limits remain attached.

Audience boundary

Current evidence is software-centered.

Climate and geospatial work are applied contexts. Energy is historical governance context and a direction of interest—not evidence of an implemented energy system. The current work does not yet establish electrical engineering, controls, embedded, power-systems, or hardware implementation experience.