In short. This essay explains the software I build and the rule it follows: a checking tool, which the essay calls a witness, can report whether a record still matches what was saved, and permission to act on that record comes from people who can answer for the choice. The rule matters to anyone affected by an automated action, because an intact record can still lead to a wrong decision. The essay applies it to each published tool, then to teaching and to outside review, and asks researchers, teachers and builders to choose a claim whose failure would matter and examine it, starting from the tool catalog or the source notes at the end.
An expanded editorial essay prepared with Codex, an AI agent from OpenAI, for Zain Dana Harper. It speaks in the author's first person, and Codex drafted that wording from his request, his published writing and the sources listed at the end. The author requested the expansion and approved the 9 September edition of this website essay for publication. On 25 September 2026 the wording was revised with Claude, an AI model from Anthropic, and the short summary above was added; approval of this revised wording is not claimed. The essay explains a program of work. The related manuscript remains in preparation; this website essay has not undergone journal peer review.
A record can be intact and the decision made from it can still be wrong. I want a person who opens my work to have enough to decide what in it deserves their time. A researcher should be able to find the source behind a result and try the check, and someone choosing a tool needs to know what goes in, what comes out and where it stops working. A person affected by an automated action needs a way to question what it was based on.
Flywheel is the application through which I am trying to connect that work. The tools around it find material, keep context, run tasks and examine what happened, and each has a specific job. The connections matter because information changes as it moves, and the limits of each step have to stay visible the whole way. A source becomes an excerpt that supports a proposal, and a success recorded now may shape a later action.
In Pick The Lock for Everyone, I wrote: “Nothing I build gets to inherit authority from the fact that I hate authority.” That sentence governs my own software. A person can find a real failure in an institution and still build a bad replacement for it. The people who use my tools need practical ways to inspect them, disagree with a result, keep their work and leave.
Entering research from outside academia
I am an independent builder with no academic background. I try to contribute through software, writing and work that other people can inspect. My portfolio shows what I have attempted, and the evidence for any one contribution belongs with that contribution, where another person can examine it.
That distinction gives me a way in and a set of duties. I have to read the earlier literature, learn the terms other people use and find out which parts of my argument someone has already established. A new name for a familiar idea makes the reader do extra work. When I borrow a method, I should credit it and explain what I changed. If I misread an established result, the correction has to stay attached to the public record.
Academic training gives people long contact with methods and with people who can spot errors a beginner cannot see yet. I want that criticism. Outside an institution, I have to ask for it on purpose and make the request easy to handle: a reviewer should get a clear question, a bounded piece of work and enough context to judge whether the claim holds up.
The same standard can help other people who come into a field by an unusual route. A research team may need a clean way to reproduce a bug, a carefully written negative result or an implementation that others can use, and each of those still needs the check that fits it. Software may need a rerun on another machine and a review of the cases where it fails. A mathematical claim needs assumptions and an argument that survive mathematical scrutiny, and a claim about people learning needs evidence from people learning.
An ORCID record, a free identifier for researchers, helps identify a person and connect their work. Publishing on my own website makes the material available to read. Neither one settles a paper's status, which has to be stated on its own: draft, preprint (a paper shared before peer review), submitted or accepted for publication. The research manuscript that goes with this program is still in preparation. Before I present it as new research, I have to state its contribution more sharply against the existing literature.
I expect AI to let more people attempt work across these boundaries. Review time will stay scarce. Someone still has to check that a convincing explanation matches the system it describes, that a citation supports its sentence and that an experiment tests the question it claims to test. Part of my job is to shrink the work I hand to that person.
What the byte witness can say
EMET compares material against a byte-level anchor that someone chose explicitly. An anchor is a fingerprint of a file's exact bytes, the raw data a computer stores, recorded at a moment someone authorized. Engineers also call such a fingerprint a hash or a digest. EMET's core specification allows three integrity results: MATCH, DRIFT and UNVERIFIABLE. In plain terms, the material still matches, the material has changed, or the check could not be done. Each result describes what that check established. A match says the comparison agreed under its stated procedure, while the accuracy of the source and any permission to act need further evidence. The specification sets that boundary, and the rationale gives the argument behind it.
I describe this component's role with the phrase byte-witness incapable of authority. In this essay a witness is a tool that reports what it checked, and a ruler would be a tool whose result counts as permission to act. EMET gets the witness role only. Its integrity result cannot grant permission. A separate component can check a signed authorization, an approval whose origin can be verified, against a policy someone has accepted. It can do that as long as it knows what the authorization covers and the current state of the system. The people who choose the policy still owe the people it affects an account of that choice.
Take a document prepared for one recipient by an AI agent, a program that carries out actions on its own, such as running commands or sending files. A reviewer approves one particular attachment. Before anything is sent, the application has to check the attachment, the destination and the permitted action against that approval. After the send, a delivery record can show what the service reported. Suppose the connection fails at a moment when nobody can tell whether the send went through. The record has to keep that uncertainty, so a retry does not quietly become a second send.
The document's fingerprint answers one part of that sequence. It says nothing about whether the recipient was the right one or whether the advice in the document was sound, and those questions have to stay open for the person who reviews the action.
A narrow vocabulary also needs care wherever it is displayed or passed on. A later component could turn a narrow match into a broad green badge. A memory system could keep the word “success” and drop the conditions under which it was recorded. The safeguards need tests at those connections, because that is where an accurate result can pick up a meaning nobody supported.
What a reviewer should be able to see
When I cite evidence for a specific claim, I want to point at the exact version of the source and the part that supports it. A citation to a whole repository, the stored files and history of a software project, leaves the reader too much to rebuild. A code reference can give the commit, one saved version in that history, along with the file, a range of lines and the relevant excerpt. A structured record can give a JSON pointer such as /actions/2/destination, with the value found there. A JSON pointer is a path to one value inside a data file. A reference to a position in text has to say how it counts, because counting bytes and counting characters can give different positions.
The excerpt also needs enough surrounding text to keep its meaning. A line that says a check passed might come from a control case, a test built to fail on purpose, or from a branch of code that never ran. A source fingerprint helps catch later changes. The reader still has to judge whether the selected material supports the claim.
For an action, the source reference belongs next to four other facts: the purpose of the task, the identity acting under its permission, the exact target and the inputs supplied. The record should separate an action someone intended from an action the system attempted. A response the system observed needs its own place in the record, with the time or sequence number that ties it to its request. If output was cut short or a source was held back, the reviewer should see that gap next to the result.
Privacy limits how much context can be shared. A public report can carry a scrubbed example, one with private details removed, and describe the private evidence a fuller review would need. An authorized reviewer may receive more through a controlled channel. The public should never be invited to treat a source value it has not seen as though it had inspected it.
These are requirements for what a reviewer experiences. The toolkit holds pieces of this work at different stages, and a finished schema (the agreed layout of a record) or a valid receipt (a saved record of what a tool did, built so someone can check it later) does not show that every action carries this context today.
A working map of the tools
The portfolio grew out of different kinds of work. Some tools have their own command-line interface, a program you run by typing commands, and their own release. Some are libraries, code meant to sit inside another application. Others are research or creative projects with a smaller public demonstration. Flywheel is meant to gather the useful connections in one place and still keep separate ways into the tools that stand on their own.
The map below explains the public product families and what each one does. It follows the published product records, and source links are available from each record. A public description tells you what a project claims to offer; running the current release on a suitable task is a further check. The descriptions here keep each tool's important limits, and where they propose a research use, it stays a proposal. The map is reference material, so a reader following the argument can skip ahead to [What has to survive the connections](#what-has-to-survive-the-connections).
Flywheel: the application through which work runs
Flywheel takes a task, a chosen route to an AI model and a set of tools, and then coordinates the run. Its Python engine and its native desktop app are two ways into that work. Optional sealed receipts for each tool call let someone inspect and recheck the recorded operations offline. For a reviewer, the useful question is what happened during this particular run, with this model and these permissions.
I intend Flywheel to be a central harness for coding and AI agents, meaning the program that runs a model with its tools, and I want it to support evaluation, research and other workflows too. A tool that is useful on its own should stay available without the whole application. Inside Flywheel, the same tool should show up where its job is needed: a researcher gathering sources should meet the source-intake tool, and a reviewer should meet the evidence and its limits. The current releases and the installed desktop app can differ. So a change in the source code needs installation and workflow checks before it becomes a claim about the application people use.
Forum: organizing dependent work
Forum turns a request into tasks that depend on each other. It can run independent tasks at the same time through local commands or model APIs, the interfaces programs use to call a model. It can pause where a person has to approve the next step and resume a run that was interrupted. Its ledger, a running log, keeps a record of the orchestration that can be replayed. That helps when one agent's result feeds another agent and an interruption would otherwise lose the link between them.
Forum's job in Flywheel is coordination. Its record can show which task ran and what that task recorded. Judging whether each result is right still needs the evidence for that task. Agents working in parallel can split the work. When they agree, their agreement carries the limits of shared dependencies that I discuss later in this essay.
Relay: carrying a coding session across model routes
Relay is a coding agent whose actions pass through permission checks. It can reach local models, subscription command-line tools, APIs and gateways, which are services that pass requests on to a model. It supports resumable sessions, failover to another route, acceptance checks and a hash-chained session record. In a hash-chained record, each entry carries a fingerprint of the one before it, so changing an earlier entry means every later fingerprint has to change too. A developer can use Relay when the work should survive a change of model endpoint, the address where a model is reached, and still keep the account of what was tried.
Relay overlaps with part of Flywheel's work. The integration needs one clear owner for session state and permissions, so two agents never each assume the other one enforced them. Relay's list of blocked commands is a convenience. It gives no general guarantee of containment, which would mean keeping an agent inside set limits. A useful evaluation would interrupt a run at a moment that matters, then inspect the recovered state and look for any action that ran twice.
Canon: taking continuity to another host
Canon turns local memory records and typed information that someone has explicitly selected into continuity capsules. Typed information here means structured data whose fields have declared types. A capsule is a package of chosen context that another AI tool, called the host, can load. Canon previews whether the target is ready. It exports Markdown or structured JSON for hosts such as Codex and Claude Code. When the caller picks a local instruction file that it owns, Canon changes only the regions declared for it.
This deals with the work that disappears when a person switches tools or starts a new session. Canon's role in Flywheel is moving chosen context, with the target and the changed region visible. It ships publicly through GitHub at the recorded release point. A capsule needs a review of its contents and permissions before it enters a new host, since being portable says nothing about whether every instruction it carries belongs there.
Mneme: retrieving memory with its history
Mneme stores conversation turns and imported source items in a local SQLite database, a small database kept in one file on your own machine. It has a command-line tool and an MCP interface. MCP, the Model Context Protocol, is a common way for AI tools to call other programs. Both return what they retrieve along with its provenance, a record of where each item came from, plus recall receipts and history views. Mneme can rank results by a mix of text relevance, vector similarity (a numeric measure of how close two passages are in meaning) and recency. Its records of what it updated and what it forgot let a maintainer see how stored material changed.
Mneme helps with one question: “where did this remembered claim come from?” Canon helps move selected continuity into another host, a related job with its own inputs and outputs. When Flywheel recalls an item, it should keep the source next to the text, along with any drift or gap. In the published account Mneme owns its own source recheck, and an independent reread by Crucible is a separate integration requirement.
Bulletin: shared agent work that people can inspect
Bulletin is a public board that AI agents can read and write over HTTP or MCP. A signing key identifies who posted. Posts and attachments are served as untrusted input. Inbox acknowledgements record which delivered page a reader says it handled. People can inspect the shared work through the board interface.
I want Bulletin to help with reporting findings, handing off work and correcting claims in public. It can also supply an environment for a carefully specified study of how agents coordinate. The board shows what was posted through it; it does not show everything that happens in other applications, prove what influenced a model, catch every malicious instruction or contain an agent. A study would show more than watching a lively conversation, and it would need to record the exact messages each agent received, keep the grader (the automated check that scores an agent's work) separate from the board and compare outcomes under declared conditions.
Finding material and understanding its structure
Index: a map with locations to inspect
Index reads a code repository's manifests, the files where a project describes itself and what it depends on, along with its imports, symbols and local documentation. From these it builds dependency maps, offline wikis, context packets and inventories of a workspace, each backed by file-and-line evidence. Background jobs handle larger scans and recovery. A user can start with a question such as where a feature lives, then follow the map back to the code.
Index's role in Flywheel is to make the choice of context more deliberate, since a good map means less need to send a whole repository to a model. Imports that load at run time and structures the scanner does not support can stay incomplete, so the map has to keep those limits visible. A missing connection may mean the scanner could not resolve it, so someone has to inspect the source before it becomes a conclusion about the architecture.
Gather: capturing the source material
Gather collects material into a corpus with provenance, where each item is stored under a fingerprint of its own content. It takes in documents, PDFs, scholarly records, feeds and media, and uses a browser or an API for sources that need one. A researcher hands it sources and gets back stored items whose origins can be checked again later.
Gather belongs before a synthesis or claim check. The intake route matters. A static web capture does not run JavaScript, and a media transcript can leave out what appears in a frame of video. A successful connection also has to produce a nonempty capture of the expected material. Those capture details should travel with the excerpt through Flywheel, where a summary should never hide them.
Chorus: examining a captured discussion
Chorus takes a captured thread or a set of comments and produces written summaries, which Chorus calls digests, that group and weight the discussion. Those summaries can be rechecked. Its review of source changes helps show whether gathered material still matches a reference set. A researcher can use it to study recurring themes without letting one hand-picked comment stand for the whole discussion.
Its sentiment component handles English only and reads it literally, so it can miss sarcasm and context. A summary is also limited by how the corpus was chosen. For Flywheel, the useful handoff runs from the material Gather captured, to the Chorus synthesis, and back to the original excerpts. A frequency or weight inside that corpus should never turn into a claim about a whole population.
Plexus: finding possible tool connections
Plexus reads tool manifests, the files where tools describe their inputs and outputs. It finds connections that the tools declare as compatible and can produce dependency graphs or pipeline scripts that run. It probes the tool routes registered in Flywheel only when someone asks.
This gives a starting point for standard interfaces, because Plexus can tell a builder that one tool declares an output that another tool accepts. A working integration also has to agree on how errors, cancellation, authentication, source locations and version changes behave. A declared connection needs a real test run before anyone presents it as working, most of all when a pipeline includes an action with real consequences.
Checking a result and accounting for an action
Crucible: testing an explicit claim
Crucible breaks a thesis into separate claims, each with a stated condition under which it fails, and checks those claims against the evidence or measurements supplied. It returns a record that can be recomputed, with the result MATCH, DRIFT or UNVERIFIABLE. The user has to say what the test examines and what would count against the claim.
Crucible helps when a task can be made precise enough to test. Its result depends on the evidence supplied, the way it was measured and the criterion chosen. In Flywheel, it can help keep a model's confident message that it finished from being the only acceptance check. The criterion still needs scrutiny of its own, including a wrong example that the checker must reject.
EMET: preserving a narrow integrity statement
EMET supplies the byte-level comparison described earlier. It fits into a pipeline wherever a later reader needs to check that the material still agrees with its declared anchor. It can support source intake, review and later replay, and its verdict keeps the same narrow scope throughout.
The work needed at each connection is about meaning: whatever uses the result has to keep what the result means. A source can arrive byte for byte and still contain a falsehood. An intact authorization record can fall outside the scope of a new action. The tool around EMET has to carry the extra checks without quietly enlarging EMET's claim.
Service Desk Incident Environment: a bounded workflow to evaluate
The Service Desk Incident Environment provides synthetic incident workflows, built from invented data. It compares the claims an agent recorded with task outcomes it recomputes, and in an offline HTML report it points out contradictions between what was authorized, the responses given and what was changed. An evaluator then has concrete changes in state to inspect and does not have to rely entirely on the agent's own account of success.
The released environment is an add-on. It needs a compatible Flywheel engine. It is a useful, bounded example of the direction of this work: choose a workflow, define the expected behavior and inspect the state that results. It supports no general conclusion about behavior in a real production service desk, or about whether a model is aligned, meaning whether it reliably does what its developers intend. A production pilot would need its own data permissions, failure cases and acceptance conditions.
Model Provenance Validator: checking the evidence record's shape
Model Provenance Validator checks JSON records that tie a claim about a model or a release to its sources, retrieval dates and publication status. It can produce a Proof Surface packet and redact output that looks like a credential, and a release reviewer can use it to find missing or malformed fields before working on the claim itself.
It does not fetch the cited source or decide whether the claim is true. In a Flywheel release workflow it can validate the record a reviewer receives, and comparing the sources and assessing safety stay separate, named tasks.
Repo Proof Index: making evidence navigable
Repo Proof Index scans proof packets, receipts and contracts. It builds an index of each one's type, status, evidence summary and source path, and it validates the packet formats it knows. A reviewer can use that index to find the artifact that bears on a question.
The index cannot show that the evidence is enough. It leaves unread the private payloads a record points to. Linked to Flywheel, the index should cut the time spent finding things and keep missing evidence in view. A private reference needs an authorized route for review, or a plain statement that this review could not see the source.
Proof Surface: structured records for review
Proof Surface validates structured records of workflows, delegation, authorization and witnessing. Its library and command-line tool build evidence packets and return verdicts or advisory decisions such as allow, deny and needs-human. The packet gives other components one common structure to inspect.
Enforcement belongs to the system around it. Producing an advisory result does not make Proof Surface run an action or grant permission. When Proof Surface is integrated with Flywheel, the component that is about to act has to check the current request against an accepted authorization and keep the exact target.
Accountable Surface: the execution boundary
Accountable Surface puts approval checks around the file, command, web and browser actions it supports. It can pause or block a request, inspect what happened and try to roll back a failure that can be reversed. A hash-chained journal records its decisions and observations.
This is the part of the portfolio concerned with carrying permission into execution. A model cannot authorize itself. The journal also needs checks at the adapter, the small piece of code that performs an action on one kind of system. Changed inputs, a stale approval and an uncertain response each have to stay a separate case. Any claim about enforcement reaches only as far as the supported adapters and their tests.
Privacy and release hygiene
Phantom: inspecting exposed machine identity
Phantom inspects the hardware identifiers that a Windows or Linux system exposes, on systems you own or are expressly authorized to examine. The changes it supports come with backup and restore paths, and the public product covers one layer of these identity surfaces. Work at the kernel and firmware level, the deepest layers of the operating system and the machine's startup code, is modeled in the product, and no end-to-end shipped claim is made for it.
I want to extend this work toward a wider privacy boundary, including protection for confidential intellectual work. That is a direction of development. Changing a machine identifier cannot, on its own, protect the contents of a prompt, a file or a provider's log. A privacy workflow that works needs explicit decisions about what leaves the machine, where it goes and what the receiving service keeps, and each of those is a separate control to design and test.
behavior-transform.io: a local I/O wrapper
behavior-transform.io wraps local file operations, subprocesses, HTTP fetches, manual input and MCP traffic. Depending on the declared mode and local text rules, it passes content through or transforms it. It records values such as hashes, counts of substitutions and return codes.
A wrapper like this makes changes to the traffic it wraps an inspectable part of the workflow. A transformation can also change meaning or hide context, so whatever consumes the output needs to know it happened. The public record has no tagged release and no independently verified entry command. Linking it to Flywheel would need a concrete contract for transformations, with tests that keep the information a reviewer needs.
Secret Redact IO: reducing accidental disclosure
Secret Redact IO is a helper library that redacts output from file reads, fetches, writes and subprocesses, and emits receipts that hold only hashes. It can support an adapter that has to record an operation without copying sensitive values into its log.
Redaction rules can miss a secret or remove material someone needs to interpret a result. So redaction should come with collecting less data in the first place and with an explicit review of output. A redacted receipt is limited by what it leaves out. It cannot stand in for the source value when a reviewer needs that value to settle a claim.
Public Surface Sweeper: checking a release handoff
Public Surface Sweeper checks a repository or portfolio before publication for missing public files, unclear README handoffs, strings that look like credentials, and release metadata. It can check whether proof packets are ready and whether delivery has drifted. It is a practical check for the moment internal work becomes something another person downloads or reads.
Its scope is release hygiene. It does not replace an analysis of dependency vulnerabilities or a security review. In Flywheel, it can become one explicit step before publication, with a report of what it checked and what fell outside the scan.
Agent Hook Pack: checks at recurring workflow points
Agent Hook Pack installs hooks, safe to share publicly, that check for secrets, guard branches, keep environments in sync and keep a repository tidy. A hook puts a check at a point where a developer might otherwise forget it.
The public package leaves out private policy layers. Each host runs hooks in its own way. An installation has to be verified in that host. The useful version is a small, visible check with a failure you can recover from. Each hidden startup instruction added to the pile makes that harder to keep.
Toolmaking, learning and creative practice
Telos: a workbench with its own automation tools
Telos is a local workbench with command-line and MCP interfaces that runs workstation checks, simulations, research proofs and experiments with models or learning. Its public record also includes automation for the browser and for Windows. Each run produces a receipt that can be rechecked.
That automation work should be assessed before anyone builds another layer for controlling a computer. For Flywheel, the practical question is which Telos adapter can perform a needed action, under which permissions, and with what result someone can observe. Interfaces before version 1.0 can change. Having an automation interface proves neither that it beats another tool nor that the currently installed integration has been accepted.
BuildLang: explicit permissions in a compiled program
BuildLang is a systems programming language with its own compiler. Each program declares what it is allowed to touch. The compiler checks those permissions and the memory rules, then produces native code by way of C. The project includes C interoperability, editor support and build receipts that can be rechecked. Its other output backends are still experimental.
BuildC is also part of the planned toolchain, though the current public map does not establish it as a separate released product. I still want the toolchain to serve more of the portfolio. For now, the work continues where it already lives, by extending the existing Python, C++, Rust and other implementations. Claiming that BuildLang outperforms Rust would take equivalent programs, compiler settings and hardware, plus measured results. This essay makes no such performance claim.
Learn: supporting the learner's own work
Learn plans study sessions from stated goals and attempts the learner writes, and it rechecks them. It includes spaced review, retrieval prompts, checks on prerequisites, tracking of misconceptions, prediction and self-explanation. Course logistics run on a separate route, which stops at graded work and other steps that need consent.
The planned link to Flywheel is a learning workflow where the person stays responsible for the attempt and can inspect the feedback. A record of completed prompts does not show that the person retained or understood anything. The education section below describes the further evidence I want these tools to help produce.
Studio Engine: a reusable scene description
Studio Engine generates shader visuals, audio and motion from a scene description that can be reused. A local command-line tool and HTTP interface can render PNG frames that come out the same every time, and they record hashes for the generated scene. A creator can change one declared input and inspect the output that changes with it.
It is still unfinished as a product. Its value to the wider tooling is creative work that can be reproduced, since the scene and render settings give another person something to run. Output that repeats exactly helps compare revisions. Artistic quality still needs human judgment.
Build Color: working with digital color
Build Color converts, compares and transforms digital color, the numbers a computer uses to describe a color. Its technical scope covers perceptual color spaces, tone mapping, chromatic adaptation, gamut mapping, ICC profiles and lookup tables, with an optional graphical interface.
Technical artists and developers can use it to see what a color transform does. It works on digital values. Measuring a physical display needs a real instrument and a suitable procedure. A link to a renderer should keep the chosen color space and transform settings, so someone can investigate an image that looks wrong.
Calibrate Pro: connecting a display change to its evidence
Calibrate Pro is a toolkit for calibrating displays on Windows. It finds displays, prepares calibration targets and works with monitor controls, profiles and lookup tables through a preview-and-confirm workflow. The graphical app proposes a supported change to the display, and a person inspects it before applying it. Its reports keep track of whether each value was measured, estimated, simulated or not measured at all.
It is a separate tool that goes beyond the product list in the current public overview. Its source describes a 2.0.0 installer and a portable package. The Windows files are unsigned. A reading from an instrument and an estimate made without a sensor carry different weight as evidence. It could link to Flywheel as a creative workflow someone can review. A source link between two projects does not establish an installed Flywheel integration. The pinned product description and workflow boundary let a reader inspect those distinctions.
Retro Engine, Gallery and Loom: visible creative work
Retro Engine is a studio that runs inside the browser for images, drawing, shaders and audio traces. It applies effects such as old hardware palettes, dithering and CRT screen processing, and it can export to Loom or hand work off there. Gallery is a public display page that sits next to it.
These pages show another use for the infrastructure: making and sharing work that people can see and hear for themselves. A useful handoff keeps enough settings to continue editing somewhere else. Each export route still needs its own acceptance check. An image with a retro look is no evidence that a historical rendering engine was restored correctly.
Engine Revival and BRender Archival: preservation with attributable evidence
Engine Revival builds and audits metadata about restoring historical engines, in a form safe to publish. It can generate a build scaffold for BRender that sits outside the original source tree. BRender Archival takes on a narrower task. It rebuilds the public Argonaut BRender source, runs the restored native code, captures renders, and packages the resulting scaffold and evidence without copying the upstream source.
This work offers a useful discipline for the wider portfolio: give the reader the input, the transformation and the result behind each specific statement. For a preservation claim, metadata and a generated build scaffold have to be labeled as what they are, and evidence that restored behavior works comes from the real historical code and a record of it running.
The graphics runtime family
Elder ENB and Truth ENB change how the game Skyrim looks, and the projects around them are technical graphics work whose terms name standard parts of game and rendering software. Elder ENB is a shader suite for Skyrim, with quality tiers, bounded cinematic effects and optional native support. Truth ENB is a separate shader suite built around computed atmosphere, clouds, exposure and tone mapping. Each has its own look and its own implementation choices. Acceptance in the live game and in the ENB host remains a release boundary. Truth's public upload is waiting on its required acceptance matrix.
ENB Runtime Core is an embedded C++ library. It identifies an ENB host that is already loaded, validates its SDK interface and coordinates callbacks and behavior around saved games. SkyrimBridge exposes game state, and operations on records or assets, through a versioned interface with an optional rendering tier. Its default public build leaves out the native replacement suite.
RAW is a D3D11 rendering platform with frame capture, GPU diagnostics, shaders that reload while it runs, and effects applied partway through a frame. Its source is public and active. No public release is claimed. These projects are concrete graphics and systems work, and their link to Flywheel could be a workflow for building, inspecting or catching regressions. Their existence establishes neither a single installed graphics product nor any result about alignment.
The controlled-private systems and older names
Some tools have public descriptions while their code and operational evidence stay private. The private-practice index states that boundary. These tools can be explained at the level already published, without releasing sensitive methods and without implying that a public description of a capability is a product you can download.
Array coordinates authorized security-assessment campaigns, with scoped approvals, supervised work and an evidence ledger. Seed is a native engine for security assessment and detection engineering, the work of writing rules that spot attacks, and its public material includes synthetic demonstrations and a stated scope for the work. ORCA manages how assessments run, along with findings, reports and the provenance of each release. These descriptions name each tool's separate responsibility. Using any of them requires a defined, authorized engagement and an approved recipient for the results.
Sofer is the private runtime that orchestrates that practice, managing campaign state, correlation, reporting and the staging of disclosures. Gate is its subsystem for release checks. Before work advances, it validates the required manifests, source and test paths, controls and the results of verification commands. A release check covers the scope and recipient it reviewed and cannot supply authority for a different operation.
Bounds checks agent actions, runtime observations and release candidates for drift from the stated intent, unsupported claims, exposure and failed test fixtures. Isomorph studies classifier and refusal behavior at inference boundaries it is authorized to test, with controlled trials and records of the results. A classifier here is an automated filter that sorts or blocks content, and an inference boundary is the point where a model receives a request and answers it. A restriction seen in one configuration needs its conditions stated. The public description supports neither a conclusion about a model's general disposition nor permission to test an unrelated service.
Kun keeps local information for recovering access to systems you own. It uses path references, redacted diagnostics, rotation notes and runbooks, which are written step-by-step procedures. It records where the authority to recover lives. It keeps no raw credentials. That makes it relevant to continuity after a failure, while secret material stays out of public evidence.
The older Aleph route now presents Checkpoint, an entry to controlled private work that describes it only at the level of purpose. The older WARDEN website route points to Proof Surface. Sofer's command-line tool also uses the name WARDEN. When you read older records, the project context matters. Renamed pages, internal forks and archived predecessors should not inflate the product list.
The possible link to Flywheel is a narrowly authorized workflow with a clear boundary for review and disclosure; a shared workspace alone does not make these tools ordinary public Flywheel modules. A public report can explain the question, describe the method at a suitable level and give a scrubbed result, one with private details removed. The protected operational evidence stays with its authorized recipient.
Typography and other studio experiments remain part of the portfolio's history. The current priority is Flywheel and the tools that support it. Additional names in the wider program, including BuildDB and BuildQL, still need a verified public product description and release boundary before this essay can explain them to the same standard. Private artifacts stay outside the inventory. This map covers the published descriptions of products and capabilities, and it makes no claim that every local project has been audited.
What has to survive the connections
In one proposed use, an evaluator gathers an incident report with Gather, the source collector, finds the relevant adapter with Index, the code map, and gives Flywheel a bounded task: reproduce the incident. Forum, the coordinator, may split the independent checks. Crucible, the claim tester, can test a stated property of the result, and EMET keeps the scope of an integrity comparison. Mneme, the memory store, can keep the finding with its source, and Canon can carry selected continuity into another host. A scrubbed account could then be shared on Bulletin, the public agent board.
Every handoff in that example needs an explicit contract. The receiving tool needs the version of the source, the selected value and what the result means. A request to share material needs an authorization tied to its destination. A cancellation or an uncertain response has to survive the handoff and must never turn into a success label. The example describes the integration I am aiming for; the essay does not claim that anyone ran and accepted this whole chain for the article.
How much the central application is worth will depend on how well it keeps this context while making the task easier for a person to finish. MCP and HTTP APIs give these tools ways to talk to each other. A shared transport still leaves questions open at the level of the application: what an empty result means, how a partial capture is shown, which convention counts positions in text and what happens when the schema version changes. Standard interfaces should settle these points with small examples and with controls built to fail on purpose.
Education as the ability to judge the work
I expect teaching and learning to change fast as AI-assisted work becomes ordinary. How fast, and in what shape, are still predictions. Schools, subjects and learners will each meet the change differently. Teachers already know a great deal about assessment, feedback and how understanding grows, and that knowledge belongs in the design of these systems.
Australia's Tertiary Education Quality and Standards Agency, known as TEQSA, published guidance on assessment in 2023. In 2025 it published a resource on putting those principles into practice. The principles call for several forms of assessment that take context into account, and for ethical participation in an AI-rich society. This is an existing reform effort the tools can learn from. It does not endorse this portfolio. TEQSA assessment principles, implementation guidance.
A field experiment by Hamsa Bastani, Osbert Bastani, Alp Sungu and their coauthors gives one reason to measure learning apart from performance with help. The setting was mathematics sessions at one high school in Turkey. Students who used a general GPT-4 interface did better than the control group during practice with the AI. On a later exam without it, they did worse than the control group. A tutor built with teaching safeguards largely mitigated that harm. The study measured short-term results in one setting, and its findings do not establish the effects of every tutor or of today's models. Published study, author-hosted paper.
For my own learning tools, I want to ask four things afterward: what the person can explain, whether they can find where a claim came from, whether they can adapt the method when a condition changes and whether they could recognize a plausible answer that breaks the problem's own assumptions. These questions should shape the lesson and the assessment from the start.
One proposed exercise starts with a small program and a claim about what it does. The learner examines the input, predicts the result and then runs the program. A second case changes the input so the first line of reasoning no longer holds, and the learner has to explain the difference and say what evidence would settle a disagreement. Any assistance can be declared and adjusted to suit the lesson. A later task can check what the learner kept. Its design should account for accessibility needs.
That exercise is a design proposal. To show that it works would take educators, a suitable comparison, clear learning outcomes and follow-up after the assisted session ends. The current tool portfolio has no established result on educational effectiveness from a study like that.
Records can help a learner show revisions and explain a choice. They can also expose private drafts, or push a learner to perform one approved style of thinking. Students need clear limits on what is collected and how long it is kept, access to their own records and a way to challenge an assessment. A software trace shows only part of what a person understood, and it can supply evidence for a conversation with someone able to judge the subject.
Learning belongs inside the mission for these reasons, and time a student gets back can matter more than time spent inside an application. The design should leave the person better able to use the method, question the tool and carry on somewhere else. Notifications and engagement measures have to serve that purpose.
Contribution needs a route to correction
For an alignment researcher, a useful place to start may be an evaluation record with a known ambiguity. For a software maintainer, it may be a bug that a small input can reproduce. I want to offer the relevant component at that size, with its assumptions and costs in view, so the person receiving it can decide whether it helps their work.
An evaluation should include an ordinary case the check is expected to accept and a deliberately wrong case it must reject. If a grader passes both, the instrument needs repair before its scores can support any conclusion. The review also has to ask which parts the agent could influence: the work it submitted, the test environment, the expected answer or the record of the result. A protected grader outside the agent's reach is an existing baseline, and any proposed improvement has to take it seriously.
Independent review takes more than a second agent agreeing. Reviewers can share sources, model behavior and incentives. A useful review records three things: what the reviewer could inspect, how the check differed from the first attempt and which dependencies are still shared. Some questions need domain experts or an experiment run by someone else, and the software should make those needs visible.
The commercial question deserves the same discipline. A tool can be worth paying for if it cuts the time needed to reconstruct an incident, catches a mistake with real consequences or makes a necessary workflow usable. A pilot should identify the current process and measure the change against it. Installing, running and reviewing a tool all take time. A catalog entry or a sent outreach message is no evidence that anyone adopted the tool or paid for it.
Safety work has its own tradeoffs. Faster orchestration may help an evaluator run a useful test and may make harmful activity easier for someone else. A public agent board carries the same kind of tradeoff: people can study collaboration on it, and misleading instructions can spread through it. Detailed records help review, though every added detail is more material to protect. A release decision has to weigh who benefits against who bears the risk, and set access limits to fit the intended use.
The person who can refuse the result
That person is whoever uses a result or is affected by it, and they need ways to inspect it, disagree with it, keep their work and leave for another tool. Pick The Lock for Everyone asks me to look at the barriers my own work puts up. Someone should be able to contribute before they learn my preferred vocabulary. A product page should explain the task it serves, installation should state what it requires, and an error should give enough context to recover from it. If a person chooses another provider or tool, their work should stay available in a form they can use.
The ethical commitments reach authorship and labor too. Source material needs an honest account of where it came from and what use was allowed. Reviewers and maintainers contribute skilled work. An AI-assisted draft still needs a person who takes responsibility for publishing it, answers corrections and states its status accurately. A system that helps produce more work should also help account for the load that work puts on other people.
Privacy protects the space where people can think, learn and change. Public scrutiny does the most good at the claim or the consequential action that needs an account. It should leave room for protected personal lives and for confidential work a person has chosen to keep private. When a review cannot go forward without that material, the report should explain the limit and the conditions under which a fuller check could happen.
I am asking researchers, teachers and builders to examine specific parts of this work. Choose a claim whose failure would matter, or a workflow that takes too much effort to review today. The tool catalog and the linked source projects are places to start. A bounded reproduction, a correction with its source, or a conversation about a real review problem gives us something concrete to improve.
Sources, authorship and revision status
The source notes give pinned references and excerpts for the central claims. The tool source map gives exact character ranges and source values for the pinned public product records. The product explanations link to their public pages and, where the code is public, to its source. Together they describe the public portfolio as it stood when the 9 September edition was reviewed, and the approval record in the source notes covers that edition. Planned connections and research uses keep their stated limits. Deploying or using any tool requires checks against its specific version.
The ethical argument follows the author's essay Pick The Lock for Everyone, especially what it says about review debt, private life and the builder's own accountability. EMET's specification supplies the integrity contract. The education section cites TEQSA's guidance and the study by Bastani and colleagues. The author's proposed exercises and expectations are separate from what those sources found.
Codex, an AI agent from OpenAI, prepared this expanded wording from the author's request, his published writing, the project sources it inspected and the cited education material. The author requested the expansion and approved the 9 September edition for publication. On 25 September 2026 the wording was revised with Claude, an AI model from Anthropic, for plain reading. That revision added a short opening summary and plain definitions of technical terms, and it was checked against the 9 September text so that the claims, sources, numbers and stated limits stay the same. It was also checked with Articulate, the author's own prose checker, which tests writing against named style rules; a pass says nothing about whether the claims are true or who wrote them. The author approved the 9 September wording. Approval of this revised wording is not claimed. The manuscript mentioned here is in preparation; this website essay has not undergone journal peer review.