## 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](https://harperz9.github.io/overview.html), 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](https://harperz9.github.io/flywheel.html) 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](https://harperz9.github.io/forum.html) 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](https://harperz9.github.io/systems/relay.html) 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](https://harperz9.github.io/canon.html) 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](https://harperz9.github.io/systems/mneme.html) 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. Its 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](https://harperz9.github.io/systems/bulletin.html) 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](https://harperz9.github.io/bulletin.html).

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](https://harperz9.github.io/index-graph.html) 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](https://harperz9.github.io/gather.html) 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](https://harperz9.github.io/chorus.html) 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](https://harperz9.github.io/systems/plexus.html) 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](https://harperz9.github.io/crucible.html) 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](https://harperz9.github.io/emet.html) 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](https://harperz9.github.io/flywheel.html#service-desk) 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](https://harperz9.github.io/security-toolkit.html#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](https://harperz9.github.io/security-toolkit.html#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](https://harperz9.github.io/proof-surface.html) 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](https://harperz9.github.io/accountable-surface.html) 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](https://harperz9.github.io/phantom.html) 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](https://harperz9.github.io/systems/behavior-transform.html) wraps local file operations, subprocesses, HTTP fetches, manual 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](https://harperz9.github.io/security-toolkit.html#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](https://harperz9.github.io/public-surface-sweeper-sample.html) 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](https://harperz9.github.io/security-toolkit.html#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](https://harperz9.github.io/systems/telos.html) 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](https://harperz9.github.io/buildlang.html) 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](https://harperz9.github.io/learn.html) 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](https://harperz9.github.io/systems/studio-engine.html) 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](https://harperz9.github.io/build-color.html) 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](https://github.com/HarperZ9/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](https://github.com/HarperZ9/calibrate-pro/blob/3d24d16d6b57b2264ac122b15a6b64530cefed26/README.md#L18) and [workflow boundary](https://github.com/HarperZ9/calibrate-pro/blob/3d24d16d6b57b2264ac122b15a6b64530cefed26/README.md#L61-L66) make those distinctions inspectable.

### Retro Engine, Gallery and Loom: visible creative work

[Retro Engine](https://harperz9.github.io/retro.html) 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](https://harperz9.github.io/loom.html). [Gallery](https://harperz9.github.io/gallery.html) 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](https://harperz9.github.io/engine-revival.html) builds and audits public-safe metadata about historical engine restoration. It can generate an out-of-tree BRender build harness. [BRender Archival](https://harperz9.github.io/brender-archival.html) 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](https://harperz9.github.io/elder-enb.html) is a shader suite for Skyrim with quality tiers, bounded cinematic effects and optional native support. [Truth ENB](https://harperz9.github.io/truth-enb.html) is a separate shader suite focused on computed atmosphere, clouds, exposure and tone mapping. Their visual character and implementation choices are independent work. Acceptance in the live game and ENB host remains a release boundary, and Truth's public upload awaits its required acceptance matrix.

[ENB Runtime Core](https://harperz9.github.io/enb-runtime-core.html) is the embedded C++ library for identifying an already-loaded ENB host, validating its SDK interface and coordinating callbacks and save-related behavior. [SkyrimBridge](https://harperz9.github.io/skyrimbridge.html) 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](https://harperz9.github.io/raw.html) 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](https://harperz9.github.io/private-practice.html) 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](https://harperz9.github.io/array.html) coordinates authorized security-assessment campaigns, with scoped approvals, supervised work and an evidence ledger. [Seed](https://harperz9.github.io/seed.html) is a native assessment and detection-engineering engine. Its public material includes synthetic demonstrations and a declared scope for the work. [ORCA](https://harperz9.github.io/orca.html) 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](https://harperz9.github.io/sofer.html) is the private orchestration runtime for that practice. It manages campaign state, correlation, reporting and disclosure staging. [Gate](https://harperz9.github.io/private-practice.html#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](https://harperz9.github.io/bounds.html) checks agent actions, runtime observations and release candidates for intent drift, unsupported claims, exposure and failed fixtures. [Isomorph](https://harperz9.github.io/isomorph.html) 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](https://harperz9.github.io/kun.html) 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](https://harperz9.github.io/aleph.html) now presents Checkpoint, a purpose-level entry to controlled private work. The older [WARDEN website route](https://harperz9.github.io/warden.html) 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.