An expanded editorial essay prepared with Codex for Zain Dana Harper. The author reviewed the direction of the first edition and requested this expansion. Personal review of the expanded wording remains pending. The essay explains a program of work; peer review and journal acceptance have not occurred.
A record can be intact and the decision made from it can still be wrong.
I want someone opening my work to have enough information to decide what deserves their time. A researcher should be able to find the source behind a result and attempt the check. Someone choosing a tool needs to understand what it takes in, what it produces, and where it stops working. A person affected by an automated action needs a way to question its basis.
Flywheel is the application through which I am trying to connect that work. Its surrounding tools deal with finding material, keeping context, running tasks and examining what happened. Each has a specific job. The connection between those jobs matters because information changes as it moves: a source becomes an excerpt, an excerpt supports a proposal, and a recorded success may later influence another action.
The boundaries have to remain visible through that movement.
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 institutional failure and still build a bad replacement. The people using my tools need practical ways to inspect them, disagree with a result, preserve their work and leave.
Entering research from outside academia
I am an independent builder without an academic background. I am trying to contribute through software, writing and inspectable work. My portfolio lets someone see what I have attempted. The evidence for a particular contribution belongs with that contribution, where another person can examine it.
That distinction gives me a route into the work and a responsibility. I need to read the earlier literature, learn the terms other people use, and discover which parts of my argument have already been established. An unfamiliar name for a familiar idea adds work for the reader. When I borrow a method, I should credit it and explain the part I changed. If I misunderstand an established result, the correction needs to remain attached to the public record.
Academic training provides sustained contact with methods and with people who can identify errors that a beginner cannot yet see. I want access to that criticism. Working outside the institution means I have to seek it deliberately and make the request manageable. A reviewer should receive a clear question, a bounded artifact and enough context to determine whether the claim survives examination.
The same standard can help other contributors whose route into a field looks different from the expected one. A useful bug reproduction, a carefully documented negative result or an accessible implementation can give a research team something it needs. The contribution still needs an appropriate check. For software, that may include reproduction on another machine and review of failure cases. A mathematical claim requires its assumptions and argument to withstand mathematical scrutiny. A claim about people learning requires evidence about people learning.
An ORCID record helps identify and connect a person's work. Publishing on my own website makes the material available. The status of a paper must separately say whether it is a draft, a preprint, submitted work or an accepted publication. The accompanying research manuscript for this program remains in preparation. Its current conceptual starting point also needs a stronger contribution before I can responsibly present it as new research.
I expect AI to let more people attempt work across those boundaries. Review effort will remain a scarce resource. Someone has to determine whether a convincing explanation matches the underlying system, whether a citation supports the sentence, and whether the experiment tests the stated question. Part of my job is to reduce the work I pass to that person.
What the byte witness can say
EMET compares material against an explicitly chosen byte-level anchor. Its core specification permits the integrity results MATCH, DRIFT and UNVERIFIABLE. These results describe what that check established. A match says that the comparison agreed under its declared procedure; accuracy of the source and permission to act require further evidence. The specification defines the boundary, and the rationale explains the argument behind it.
The phrase byte-witness incapable of authority describes the role I give this component. EMET's integrity output cannot grant permission. Another component can check a signed authorization against an accepted policy, provided the relevant scope and current state are available. The people who choose that policy still owe an account of their choice to those it affects.
Consider a document that an agent has prepared for one recipient. The reviewer approves a particular attachment. Before the send, the application needs to check that attachment, the destination and the permitted action against the approval. Afterward, a delivery observation can establish what the service reported. If the connection fails at an uncertain moment, the record must preserve that uncertainty so a retry does not quietly become a second send.
The document's digest answers one part of that sequence. It carries no account of whether the recipient was appropriate or the document's advice was sound. Those questions have to remain available to the person reviewing the action.
A restricted vocabulary also needs careful treatment in the interface. A downstream component could turn a narrow match into a broad green badge. A memory system might retain the word “success” while discarding the conditions under which it was recorded. The controls need tests at those connections, where an accurate result can take on an unsupported meaning.
What a reviewer should be able to see
A citation to an entire repository leaves too much reconstruction to the reader. For a specific claim, I want the source version and the part that supports it. A code reference can give a commit, file and line range with the relevant excerpt. A structured record can give a JSON pointer such as /actions/2/destination, together with the value at that pointer. Text offsets need a declared convention, including whether they count bytes or characters.
The excerpt also needs enough surrounding context to preserve its meaning. A line that says a check passed might belong to a deliberately failing control or a skipped branch. A source hash helps detect later changes; the reader still has to determine whether the selected material supports the claim.
For actions, that source reference belongs with the purpose of the task, the identity acting under its permission, the exact target and the supplied inputs. The record should distinguish an intended action from an attempted one. An observed response needs its own location, with the time or sequence needed to connect it to the request. If output was truncated or a source withheld, the reviewer should see the omission beside the result.
Privacy affects how much context can be shared. A public report can carry a scrubbed example and describe the private evidence needed for a fuller review. An authorized reviewer may receive more through a controlled route. The public should never be invited to treat an undisclosed source value as though it had already inspected it.
These are requirements for the review experience. The toolkit contains pieces of this work at different stages. Completing a schema or producing a valid receipt does not establish that every action supplies this context today.
A working map of the tools
The portfolio has grown through different kinds of work. Some tools have their own command-line interface and release. Some are libraries that belong inside another application. Others are research or creative work with a narrower public demonstration. Flywheel is intended to bring the useful connections into one place while leaving independent entrypoints available.
The following map explains the public product families and their roles. It follows the published product records, with source links available from each record. A public description establishes what a project claims to offer. Running its current release against an appropriate task is a further check. The descriptions here preserve material limits, and the proposed research uses remain proposals.
Flywheel: the application through which work runs
Flywheel takes a task, a selected model route and a set of tools, then coordinates the run. Its Python engine and native desktop client provide different ways into that work. Optional sealed tool-call receipts let someone inspect and recheck the recorded operations offline. The useful question for a reviewer is what happened during this particular run, with this model and these permissions.
My intended product is a central coding and agent harness that can also support evaluation, research and other workflows. An independently useful tool should remain accessible without requiring the whole application. Inside Flywheel, the same tool should appear where its function is needed. A researcher gathering sources should encounter source intake; a reviewer should encounter evidence and its limits. The current releases and installed desktop can differ, so a source change needs installation and workflow checks before it becomes a claim about the application people are using.
Forum: organizing dependent work
Forum turns a request into tasks with dependencies. It can run independent tasks in parallel through local commands or model APIs, pause at a human approval point and resume an interrupted run. Its ledger preserves a replayable account of the orchestration. This helps when one agent's result is an input to another and an interruption would otherwise lose the relationship.
Within Flywheel, Forum's role is coordination. The orchestration record can show which task ran and what it recorded. Reviewing the substance of each result still requires the task's evidence. Parallel agents can divide the work, but their agreement has the shared-dependency limits discussed later in this essay.
Relay: carrying a coding session across model routes
Relay is a permission-gated coding agent with routes to local models, subscription command-line tools, APIs and gateways. It supports resumable sessions, route failover, acceptance checks and a hash-chained record of the session. A developer can use it when the work should survive a change in model endpoint without losing the account of what was attempted.
This overlaps with part of Flywheel's work. The integration needs a clear owner for session state and permissions so two agents do not each assume the other enforced them. Relay's command denylist is a convenience control; it supplies no general containment guarantee. A useful evaluation would interrupt a run at a consequential point and inspect both the recovered state and any duplicated action.
Canon: taking continuity to another host
Canon converts explicitly selected local memory records and typed information into continuity capsules. It previews a target's readiness and exports Markdown or structured JSON for hosts such as Codex and Claude Code. When the caller chooses a local instruction file that it owns, Canon limits its changes to declared regions.
This addresses the work lost when a person changes tools or starts a new session. Canon's place in Flywheel is the transfer of chosen context, with the target and changed region visible. Its public distribution is through GitHub at the recorded release point. The capsule needs a review of its contents and permissions before it enters a new host; portability alone says nothing about whether every retained instruction is appropriate there.
Mneme: retrieving memory with its history
Mneme stores conversation turns and imported source items in a local SQLite database. Its CLI and MCP interface return retrieved material with provenance, recall receipts and history views. Ranking can combine text relevance, vectors and recency. Update and forgetting records let a maintainer inspect how stored material changed.
Mneme helps with the question “where did this remembered claim come from?” Canon helps move selected continuity into another host. Those are related jobs with different inputs and outputs. When Flywheel recalls an item, it should preserve the source and any drift or omission beside the text. Mneme's source recheck remains owned by Mneme in the published account; an independent Crucible reread is a separate integration requirement.
Bulletin: shared agent work that people can inspect
Bulletin is a public board that agents can read and write over HTTP or MCP. A signing key identifies the poster. Posts and attachments are served as untrusted input, and inbox acknowledgements record which delivered page a reader reports handling. People can inspect the shared work through the board interface.
I want this to be useful for reporting findings, handing off work and correcting claims in public. It can also supply an environment for a carefully specified coordination study. The board shows what was posted through it. It does not show all activity in other applications, prove what influenced a model, detect every malicious instruction or contain an agent. A study would need to record exact delivered messages, keep the grader independent of the shared board and compare outcomes under declared conditions. Those measurements would establish more than watching a lively conversation.
Finding material and understanding its structure
Index: a map with locations to inspect
Index reads repository manifests, imports, symbols and local documentation. It produces dependency maps, offline wikis, context packets and workspace inventories with file-and-line evidence. Background jobs support larger workspace scans and recovery. The user can start with a question about where a capability lives and follow the map back to the code.
Its role in Flywheel is to make selection of context more deliberate. A useful map reduces the need to send an entire repository to a model. Dynamic imports and unsupported structures can remain incomplete, so the map has to preserve those limits. An absent edge may mean the scanner could not resolve the relationship. It needs source inspection before becoming an architectural conclusion.
Gather: capturing the source material
Gather collects material into a content-addressed corpus with provenance. Its intake routes include documents, PDFs, scholarly records, feeds and media, with browser or API routes for sources that require them. A researcher gives it sources to collect and receives stored items whose origins can be revisited.
Gather belongs before a synthesis or claim check. The chosen intake route matters: static web capture does not run JavaScript, and a media transcript can omit information visible in a frame. A successful connection also needs a nonempty capture of the expected material. In Flywheel, those capture details should travel with the excerpt rather than disappearing behind a summary.
Chorus: examining a captured discussion
Chorus takes a captured thread or comment corpus and produces clustered, weighted digests that can be rechecked. Its source-change review gate helps determine whether gathered material still matches a reference set. This can help a researcher examine recurring themes without treating one selected comment as the entire discussion.
The sentiment component is English and literal; sarcasm and context can be missed. A digest is also limited by how the corpus was selected. For Flywheel, the useful connection is from Gather's captured material to Chorus's synthesis and back to the underlying excerpts. A frequency or weight in that corpus should not become a claim about a whole population.
Plexus: finding possible tool connections
Plexus reads tool manifests describing inputs and outputs. It finds declared compatible connections and can produce dependency graphs or runnable pipeline scripts. Probing registered Flywheel lanes is an explicit operation.
This provides a starting point for interface standardization. It can tell a builder that one tool declares an output another tool accepts. A usable integration must also agree on error behavior, cancellation, authentication, source locators and version changes. A declared connection needs a real probe before it is presented as working. That distinction is especially important when a pipeline includes a consequential action.
Checking a result and accounting for an action
Crucible: testing an explicit claim
Crucible breaks a thesis into claims with stated failure conditions, then checks them against supplied evidence or measurements. It returns a recomputable record with MATCH, DRIFT or UNVERIFIABLE. A user has to specify what the test is examining and what would count against the claim.
Crucible is useful when a task can be made precise enough to test. Its result depends on the supplied evidence, measurement method and criterion. Within Flywheel, that can help prevent a model's confident completion message from being the only acceptance check. The criterion itself still needs scrutiny, including a wrong example that the checker must reject.
EMET: preserving a narrow integrity statement
EMET supplies the byte-level comparison described earlier. Its place in a pipeline is wherever a later reader needs to check whether the material still agrees with the declared anchor. It can support source intake, review and later replay while retaining the narrow scope of its verdict.
The work required at the connection is semantic: a consumer must preserve what the result actually means. A source can be faithfully transmitted and contain a falsehood. An intact authorization record can be outside the scope of a new action. The surrounding tool needs to carry the additional checks without silently enlarging EMET's claim.
Service Desk Incident Environment: a bounded workflow to evaluate
The Service Desk Incident Environment supplies synthetic incident workflows. It compares recorded claims with recomputed task outcomes and identifies contradictions between authorization, responses and mutations in an offline HTML report. This gives an evaluator concrete state changes to inspect rather than relying entirely on the agent's description of success.
The released environment is an add-on requiring a compatible Flywheel engine. It is a useful bounded example of the direction: choose a workflow, define the expected behavior and inspect the resulting state. It supplies no general conclusion about behavior in a production service desk or about the alignment of a model. 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 connect a model or release claim to sources, retrieval dates and publication status. It can produce a Proof Surface packet and redact credential-like output. This helps a release reviewer locate missing or malformed fields before pursuing the substantive claim.
It does not fetch the cited source or determine whether the claim is true. In a Flywheel release workflow, it can validate the record supplied to a reviewer while leaving the source comparison and safety assessment as explicit further work.
Repo Proof Index: making evidence navigable
Repo Proof Index scans proof packets, receipts and contracts and builds an index of their type, status, evidence summary and source path. It validates known packet formats. A reviewer can use the resulting index to find the artifact relevant to a question.
The index cannot establish that the evidence is sufficient, and it does not read referenced private payloads. Its connection to Flywheel should reduce navigation work while preserving missing evidence. A private reference needs an authorized review route or a clear statement that the source was unavailable to this review.
Proof Surface: structured records for review
Proof Surface validates structured workflow, delegation, authorization and witness records. Its library and CLI build evidence packets and return verdicts or advisory decisions such as allow, deny and needs-human. The packet gives other components a common structure to inspect.
Enforcement belongs to the surrounding system. Proof Surface does not execute an action or grant permission by producing an advisory result. This separation matters when integrating it with Flywheel: the component about to act must check the current request against an accepted authorization and preserve the exact target.
Accountable Surface: the execution boundary
Accountable Surface implements approval checks around supported file, command, web and browser actions. It can pause or block a request, inspect the outcome and attempt rollback for reversible failures. A hash-chained journal records decisions and observations.
This is the part of the portfolio concerned with carrying permission into execution. The model cannot provide its own authorization. A journal also needs checks at the actual adapter: changed inputs, a stale approval or an uncertain response must remain distinct cases. The supported adapters and their tests define the boundary of any enforcement claim.
Privacy and release hygiene
Phantom: inspecting exposed machine identity
Phantom inspects hardware identifiers exposed by owned or expressly authorized Windows and Linux systems. Its supported changes use backup and restoration paths. The public product boundary covers a particular layer of identity surfaces; kernel and firmware work is modeled without an end-to-end shipped claim.
I want to extend this work toward a broader privacy boundary, including protection of confidential intellectual work. That is a development direction. Changing a machine identifier cannot by itself protect the contents of a prompt, file or provider log. An effective privacy workflow needs explicit decisions about what leaves the machine, which destination receives it and what the receiving service retains. Those are separate controls to design and test.
behavior-transform.io: a local I/O wrapper
behavior-transform.io wraps local file operations, subprocesses, HTTP fetches, operator input and MCP traffic. Depending on the declared mode and local text rules, it passes through or transforms content and records values such as hashes, substitution counts and return codes.
Such a wrapper makes changes to tool traffic an inspectable part of the workflow. A transformation can also alter meaning or hide relevant context, so a consumer needs to know it occurred. The public record has no tagged release or independently verified entry command. Connecting it to Flywheel would require a concrete transformation contract and tests that preserve the information a reviewer needs.
Secret Redact IO: reducing accidental disclosure
Secret Redact IO is a helper library for redacting file, fetch, write and subprocess output while emitting hash-only receipts. It can support an adapter that needs to record an operation without copying sensitive values into its log.
Redaction rules can miss a secret or remove material needed to interpret a result. For that reason, redaction should accompany data minimization and explicit output review. A redacted receipt has an omission boundary; 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, credential-like strings and release metadata. It can inspect proof-packet readiness and delivery drift. This is a practical check for the moment when internal work becomes something another person downloads or reads.
Its scope is release hygiene. It is not a substitute for dependency vulnerability analysis or a security review. In Flywheel, it can become one explicit pre-publication step with a report of what it checked and what remained outside the scan.
Agent Hook Pack: checks at recurring workflow points
Agent Hook Pack installs public-safe hooks for secret checks, branch guards, environment synchronization and repository hygiene. A hook places a check at a point where a developer might otherwise forget it.
The public package omits private policy layers. Each host also has its own hook behavior, so installation needs verification in that host. The useful integration is a small, visible check with a recoverable failure, rather than a growing pile of hidden startup instructions.
Toolmaking, learning and creative practice
Telos: a workbench with its own automation tools
Telos is a local workbench with CLI and MCP interfaces for workstation checks, simulations, research proofs and model or learning experiments. Its public record also includes browser and Windows automation. A run produces a receipt that can be rechecked.
That existing automation work deserves assessment before another computer-use layer is built. Within Flywheel, the practical question is which Telos adapter can perform a required action, under which permissions, with what observable result. Pre-1.0 interfaces can change. The presence of an automation interface establishes neither superior performance to another tool nor acceptance of the currently installed integration.
BuildLang: explicit permissions in a compiled program
BuildLang is a systems language and compiler. Programs declare what they are allowed to touch, and the compiler checks those permissions and memory rules before producing native code through C. The project includes C interoperability, editor support and recheckable build receipts; additional output backends remain experimental.
BuildC is also part of the intended toolchain program; the current public map does not establish it as a separate released product. I still want the toolchain to become useful for more of the portfolio. For now, extending the existing Python, C++, Rust and other implementations lets the work proceed where it already lives. A claim of outperforming Rust requires equivalent programs, compiler settings, hardware and measured results. This essay makes no such performance claim.
Learn: supporting the learner's own work
Learn plans and rechecks study sessions from declared objectives and learner-authored attempts. It includes spaced review, retrieval prompts, prerequisite checks, misconception tracking, prediction and self-explanation. Course logistics are a separate route that stops at graded work and other consent-sensitive steps.
The intended connection to Flywheel is a learning workflow in which the person remains responsible for the attempt and can inspect the feedback. A record of completed prompts does not establish retention or understanding. 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 reusable scene description. A local CLI and HTTP interface can render deterministic PNG frames and record hashes for the generated scene. A creator can change one declared input and inspect the corresponding output.
It remains unfinished as a product. Its useful relationship to the wider tooling is reproducible creative work: the scene and render settings provide something another person can run. Deterministic output helps compare revisions, while artistic quality still needs human judgment.
Build Color: working with digital color
Build Color converts, compares and transforms digital color. Its functions include perceptual spaces, tone mapping, chromatic adaptation, gamut mapping, ICC profiles and lookup tables, with an optional graphical interface.
This helps technical artists and developers inspect the consequences of a color transform. It works on digital representations; physical display measurement needs an actual instrument and an appropriate procedure. A connection to a renderer should preserve the chosen color space and transform parameters so an apparently wrong image can be investigated.
Calibrate Pro: connecting a display change to its evidence
Calibrate Pro is a Windows display-calibration toolkit. It discovers displays, prepares calibration targets and works with monitor controls, profiles and lookup tables through a preview-and-confirm workflow. The graphical application proposes a supported display change for a person to inspect before applying it. Reports preserve whether a value was measured, estimated, simulated or not measured.
This is a distinct tool beyond the current public overview's product list. Its source describes a 2.0.0 installer and portable package; the Windows artifacts are unsigned. Instrument measurements and sensorless estimates have different evidential status. Its possible connection to Flywheel is a reviewable creative workflow, but a source link between projects does not establish an installed Flywheel integration. The pinned product description and workflow boundary make those distinctions inspectable.
Retro Engine, Gallery and Loom: visible creative work
Retro Engine is an embedded browser studio for images, drawing, shaders and audio traces. It applies effects such as hardware palettes, dithering and CRT processing, with exports and handoffs into Loom. Gallery provides an adjacent public presentation surface.
These pages show another purpose for the infrastructure: making and sharing work that people can experience directly. A useful handoff preserves enough settings to continue editing elsewhere. Each export route still needs its own acceptance check. A retro-looking image provides no evidence that a historical rendering engine was restored correctly.
Engine Revival and BRender Archival: preservation with attributable evidence
Engine Revival builds and audits public-safe metadata about historical engine restoration. It can generate an out-of-tree BRender build harness. BRender Archival addresses a more specific task: rebuilding public Argonaut BRender source, running restored native code, capturing renders and packaging the resulting harness and evidence without copying the upstream source.
The distinction matters to a preservation claim. Metadata and a generated build scaffold need to be identified as such. Evidence for restored behavior comes from the actual historical code and its recorded execution. This work offers a useful discipline for the wider portfolio: give the reader the input, the transformation and the result that supports the particular statement.
The graphics runtime family
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 focused on computed atmosphere, clouds, exposure and tone mapping. Their visual character and implementation choices are independent work. Live game and ENB acceptance remains a release boundary, and Truth's public upload awaits its required acceptance matrix.
ENB Runtime Core is the embedded C++ library for identifying an already-loaded ENB host, validating its SDK interface and coordinating callbacks and save-related behavior. SkyrimBridge exposes game state and record or asset operations through a versioned interface, with an optional rendering tier. Its default public build excludes the native replacement suite.
RAW is a D3D11 rendering platform with frame capture, GPU diagnostics, hot-reloaded shaders and mid-frame effects. It has active public source without a public release claim. These projects supply concrete graphics and systems work. Their connection to Flywheel is a possible build, inspection or regression workflow; the existence of the projects does not establish a unified installed graphics product or an alignment result.
The controlled-private systems and older names
Some tools have public descriptions while their implementations and operational evidence remain private. The private-practice index states that boundary. They can be explained at the level already published without releasing sensitive methods or implying that a public capability description is a downloadable product.
Array coordinates authorized security-assessment campaigns, with scoped approvals, supervised work and an evidence ledger. Seed is a native assessment and detection-engineering engine. Its public material includes synthetic demonstrations and a declared scope for the work. ORCA manages assessment execution, findings, reports and their release provenance. These descriptions identify their different responsibilities. Actual use requires a defined authorized engagement and an approved recipient for its results.
Sofer is the private orchestration runtime for that practice. It manages campaign state, correlation, reporting and disclosure staging. Gate is its release-check subsystem, validating required manifests, source and test paths, controls and verification-command results before advancement. A release check applies to the reviewed scope and recipient; it cannot supply authority for a different operation.
Bounds checks agent actions, runtime observations and release candidates for intent drift, unsupported claims, exposure and failed fixtures. Isomorph examines classifier and refusal behavior at authorized inference boundaries, with controlled trials and records of the results. A restriction observed in one configuration needs its stated conditions. The public description supplies no conclusion about a model's general disposition or permission to test an unrelated service.
Kun keeps local access-recovery information for owned systems through path references, redacted diagnostics, rotation notes and runbooks. It records where recovery authority can be found without retaining raw credentials. That makes it relevant to continuity after a failure while keeping secret material out of public evidence.
The older Aleph route now presents Checkpoint, a purpose-level entry to controlled private work. The older WARDEN website route points to Proof Surface. Sofer's CLI also uses the name WARDEN, which makes the project context important when reading older records. Renamed pages, internal forks and archived predecessors should not inflate the product list.
These tools do not become ordinary public Flywheel modules merely because they share a workspace. The possible connection is a narrowly authorized workflow with a clear review and disclosure boundary. Public reporting can explain the question, the method at an appropriate level and a scrubbed result, while protected operational evidence remains with its authorized recipient.
Typography and other studio experiments remain part of the portfolio's history. The current priority is Flywheel and the supporting tools. 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 remain outside the inventory. This map covers the published product and capability descriptions; it does not claim that every local project has been audited.
What has to survive the connections
The intended workflow is easier to understand through a specific proposed use. An evaluator gathers an incident report with Gather, locates the relevant adapter in Index and gives a bounded reproduction task to Flywheel. Forum may divide independent checks. Crucible can examine a stated property of the result, while EMET preserves the scope of an integrity comparison. Mneme can retain the finding with its source; Canon can carry selected continuity into another host. A scrubbed account could then be shared on Bulletin.
Every transition in that example needs an explicit contract. The receiving tool needs to know the source version, the selected value and the meaning of the result. A request to share material needs a destination-bound authorization. A cancellation or uncertain response needs to survive transfer without becoming a success label. The example describes the integration target; it is not a claim that this entire chain was run and accepted for the article.
MCP and HTTP APIs provide ways for these tools to communicate. Common transports still leave application-level questions: what does an empty result mean, how is a partial capture represented, which offset convention is used, and what happens when the schema version changes? Standardization should settle those questions with small examples and failing controls. The value of the central application will depend on how well it preserves that context while making the task easier for a person to complete.
Education as the ability to judge the work
I expect educational practice to change quickly as AI-assisted work becomes ordinary. The speed and shape of that change remain predictions. Schools, disciplines and learners will experience it differently. Teachers already have substantial knowledge about assessment, feedback and how understanding develops; that knowledge belongs in the design of these systems.
Australia's Tertiary Education Quality and Standards Agency published assessment guidance in 2023 and followed it with guidance on putting reform into practice in 2025. Its principles call for multiple forms of assessment that account for context, alongside ethical participation in an AI-rich society. This is an existing reform effort that 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 separately from assisted performance. In mathematics sessions at one Turkish high school, students using a general GPT-4 interface performed better during assisted practice but worse on a subsequent unassisted exam than the control group. A tutor designed with instructional safeguards largely mitigated that harm. The study measured short-term outcomes in a specific setting; its findings do not establish the effects of every tutor or today's models. Published study, author-hosted paper.
For my own learning tools, I want to ask what the person can explain afterward. Can they locate the source of a claim? When a condition changes, can they adapt the method? Could they recognize a plausible answer that violates the problem's assumptions? These questions should influence the lesson and the assessment from the start.
One proposed exercise begins with a small program and a claim about its behavior. The learner examines the input, predicts the result, then runs it. A second case changes the input so the original reasoning no longer applies. The learner has to explain the difference and identify what evidence would settle a disagreement. Assistance can be declared and adjusted to the lesson. A later task can examine what the learner retained, with accessibility needs accounted for in its design.
That exercise is a design proposal. A convincing demonstration would require educators, a suitable comparison, clear learning outcomes and follow-up beyond the assisted session. The present tool portfolio has no established educational-effectiveness result from such a study.
Records can help a learner show revisions and explain a decision. They can also expose private drafts or create pressure to perform a prescribed style of thinking. Students need clear boundaries around collection and retention, access to their own records and a way to challenge an assessment. A software trace cannot reveal everything a person understood. It can supply evidence for a conversation with someone capable of judging the subject.
This is why learning belongs inside the mission. The design should leave the person better able to use the method, question the tool and continue elsewhere. Notifications and engagement measures need to serve that purpose. Time returned to a student's life can matter more than time retained inside an application.
Contribution needs a route to correction
For an alignment researcher, the useful starting point may be an evaluation record with a known ambiguity. For a maintainer, it may be a bug that can be reproduced from a small input. I want to offer the relevant component at that scale, with the assumptions and costs visible, so the recipient 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 gives both a pass, the instrument needs repair before its scores can support a conclusion. The review also has to ask which parts the agent could influence: the submitted artifact, the test environment, the expected answer or the record of the result. A protected external grader is an existing baseline that any proposed improvement must take seriously.
Independent review requires more than a second agent's agreement. Reviewers can share sources, model behavior and incentives. A useful review records what the reviewer could inspect, how the check differed from the original attempt, and which dependencies remain shared. Some questions require domain experts or an independently performed experiment. The software should make those needs visible.
The commercial question deserves the same discipline. A tool can be worth paying for if it reduces the time needed to reconstruct an incident, catches a consequential mistake or makes a necessary workflow usable. A pilot should identify the current process and measure the change against it. Installation, operation and review all cost time. A catalog entry or a sent outreach message supplies no evidence of adoption or revenue.
Safety work carries its own tradeoffs. Faster orchestration may help an evaluator run a useful test, while also making harmful activity easier for someone else. A public agent board can help examine collaboration and can spread misleading instructions. More detailed records help review and increase the amount of material that must be protected. Release decisions need to consider who benefits, who bears the risk and which access boundaries fit the intended use.
The person who can refuse the result
Pick The Lock for Everyone asks me to examine the barriers my own work creates. Someone should be able to contribute before they know my preferred vocabulary. The product page should explain the task it serves. Installation should state its requirements, and an error should give enough context to recover. If the person chooses another provider or tool, their work should remain available in a usable form.
The ethical commitments extend to authorship and labor. Source material needs an honest account of where it came from and what use was permitted. Reviewers and maintainers contribute skilled work. An AI-generated draft still needs a person who accepts responsibility for publishing it, responds to corrections and represents its status accurately. A system that helps produce more work should also help account for the burden that work places on others.
Privacy protects the space in which people can think, learn and change. Public scrutiny is most useful at the claim or consequential action that needs an account. It should leave room for protected personal lives and for confidential work that a person has chosen to keep private. When a review cannot proceed without that material, the report should explain the limit and the conditions under which a fuller check could occur.
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 currently takes too much effort to review. The tool catalog and linked source projects provide starting points. 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 provide pinned references and excerpts for 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 implementation sources. They describe the public portfolio at this edition's review point. Planned connections and research applications retain their stated limits; deployment and use require version-specific checks.
The ethical argument follows the author's Pick The Lock for Everyone, especially its discussion of 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 Bastani and colleagues' study; the author's proposed exercises and expectations are separate from those sources' findings.
Codex prepared this expanded wording from the author's request, published writing, inspected project sources and the cited education material. The author expressed support for the first edition's direction and authorized expansion and publication. Personal review of this expanded wording remains pending. The manuscript mentioned here is in preparation; this website essay has not undergone journal peer review.