Skip to content

Services

The lab works for hire.

Everything in the Lab was designed, engineered, and instrumented in-house — the same hands and the same standards are available for your problem. Small engagements, concrete deliverables, no decks where a working thing should be.

Eleven ways in: four anchor engagements and seven broken-out offerings — every skill the lab has used in any project, offered on its own. The projects appear only as proof, and status honesty is part of the offer: thesis-stage things are sold as thesis-stage thinking, never as shipped instruments.

Anchor engagements

Feasibility studies — a build/no-build answer you can defend

Living record · last filed as “Feasibility, honestly”

Before money moves on a hard idea, the physics gets a vote: what it weighs, what it draws, where it breaks — and whether to build at all. A physics-led, numbers-first study of the idea’s envelope — mass and power budgets, bill-of-materials shape, the safety story, coverage and its honest exceptions — the discipline that worked the Wash Bot to buildable before a single part is ordered, and specified Cordless Electricity’s power, optics, and safety end to end at concept stage. You get a written build/no-build case you can defend, and when the answer is build, the plan is shovel-ready: completely planned, waiting only on resources and a green light.

Proof Wash Bot →Cordless Electricity →

Instruments & dashboards — the state you can’t see, rendered live

Living record · filed as “Instruments & dashboards” since the first catalog — the name held

When a system’s important state is invisible, the answer is not a better argument about it — it is an instrument that renders it. Live tooling for problems that need eyes on them — auditors, monitors, visualizers — built to the lab’s three instrument properties: observable, continuous, truthful — nothing drawn for effect. CodeRadar’s live dashboard and the IMAXING interactive volume are house-built instruments of exactly this kind; the engagement builds the same calibre of instrument on your real system, with a written account of what it measures and what it deliberately does not.

Proof CodeRadar →IMAXING →Instrumentation →

AI code audit — the counterfeit-code audit

Living record · last filed as “AI with receipts”

Machine-generated code that runs, reads clean, and does no real work survives review precisely because it does not look wrong — the audit that catches it has to be math, not another model’s opinion. Your codebase is audited against the four invariants every legitimate implementation must satisfy, with deterministic, binary verdicts: no scores, no thresholds, no confidence percentages. You get a findings ledger — rule-coded infractions with severity — one vetted before/after repair per finding, and state mirrors so the audit trail outlives the fix. The boundary is stated up front: the invariants catch code that does no real work, not code that does the wrong real work — the audit bounds review; it does not replace it.

Proof CodeRadar →Counterfeit code →Code provenance →

Robotics & mechanism design — machines whose worst failure mode is a soft bump

Living record · last filed as “Automation & robotics design”

From napkin to systems design: architecture and packaging (the Wash Bot’s four articulated quadrants around a central service spine, balanced by allocation, not ballast), the mechanism physics that carries the claim (a dual-lip adhesion skirt holding vacuum across panel breaks), and fleet choreography (mower units holding for pedestrians, self-docking at the truck that brought them). Safety is designed as a property of the machine, in two layers — a reactive floor that is the guarantee, and a predictive layer above it so the guarantee almost never fires. Where hardware is expensive, targeted simulation carries the proof burden — and the design states plainly which claims are simulation-validated rather than field-validated.

Proof Wash Bot →Autonomous Mowers →Human-aware safety →Adhesion →

Broken-out offerings

Web design & build — a site that is its own performance argument

If a site about your work spins up the reader’s laptop fan, it is arguing against itself. The lab designs and builds sites the way it built its own: everything in-house, animations hand-written in Canvas and SVG driven by one shared clock, no frameworks of convenience, no trackers, no cookies — and the whole site shipping, as its about page argues, in well under a megabyte. Where a page could drift from its data, the data is made the single source of truth and the build is made to fail on disagreement: add a page this site’s transit map does not know, and the build fails until the map is redrawn. perpetualrnd.com itself, including that map, is the standing proof.

Proof The site itself →Where the standard is stated →

QA & test automation — checks that fail loudly while the work happens

A claim no machine re-checks is a claim that quietly stops being true; the fix is verification that runs at the speed the work is produced. The lab automates verification at three altitudes it already practices: build-time invariants that make drift impossible (this site’s own data model throws at module init — a renamed key fails the build, not the reader), save-time validation pipelines (CodeRadar goes from file save to verdict in seconds — deterministic, local, offline), and simulation suites that carry the proof burden where physical testing is expensive (the Wash Bot’s multi-fidelity suite). You get the checks, the pipeline that runs them continuously, and a written map of what is now machine-verified versus still assumed.

Proof CodeRadar →Wash Bot →The site’s own build →

Verification gates in CI — the CodeRadar method, detached from the tool

Changes now arrive faster than any reviewer reads; the gate that holds has to be deterministic math, wired into the pipeline itself. CodeRadar’s method, applied to your CI rather than sold as a dashboard: pure-predicate checks on the syntax tree, binary verdicts that are the same on every run, completion-gated startup with incremental validation, and state mirrors that record findings and before/after repairs so the audit trail outlives the fix. In the full configuration the lab has documented, coordinated agents resume building only when the mirrors read zero — provable clean state, not a feeling. The same gate logic holds a human team’s pipeline: counterfeit work stops at the gate instead of being absorbed and filed under bad luck.

Proof CodeRadar →Code provenance →Counterfeit code →

Agentic & LLM workflow design — build loops you don’t have to trust blind

Agents produce work faster than anyone can read it; the workflow answer is independent verification standing between the machine that builds and the state you rely on. The lab designs multi-seat AI build loops with verification as a separate, independent seat: builders build, a deterministic checker gates, and work resumes only on a provable clean state — the configuration CodeRadar documents. The design principle throughout: a probabilistic worker needs a non-probabilistic gate wherever one is possible, because a model that hallucinates code can hallucinate a passing verdict. The lab also brings its thesis-stage thinking on long-run human–LLM collaboration — the Replacing Resumes argument that the record of real working interaction is itself valuable evidence — offered as thesis and method, never as a shipped instrument.

Proof CodeRadar →Replacing Resumes →Instrumentation →

Explanatory animation & data visualization — the work, made watchable

Real engineering nobody can see gets treated as a claim; a film or a live visual turns it into something an audience watches happen. The lab writes its films by hand: six episode animations — one per experiment — each a self-contained Canvas piece with an authored treatment, staged like cinema and accurate to the engineering it depicts, because the closeups are the same physics the dossiers claim. The engagement is that craft applied to your system: an explanatory film or a data visual in which nothing is drawn for effect, delivered with the authored treatment behind it, beat by beat. The films play in context on the six project pages below.

Proof CodeRadar →IMAXING →Cordless Electricity →Wash Bot →Autonomous Mowers →Replacing Resumes →

AI interpretability & eval tooling — which route carried the thought?

A model gives you an answer and no account of how; an interpretability instrument renders the route so the account can be inspected. The lab builds instruments for looking inside models, on the pattern IMAXING proves: a prompt rendered as a volume — token strands climbing the layer axis, contrast prompts hanging as fog — with dye emitters injecting signal at a chosen layer and feature, sparse-autoencoder bottles marking the top features per layer, and attribution edges connecting the route; the method is baseline-versus-perturbed runs, per token, per layer. The engagement fits that pattern — or an eval harness built on the same instrument honesty — to your model and your question, with the honest accounting attached: dimensionality reduction loses structure, and a lit path is strong evidence of a route, not a causal proof. The full-fidelity blueprint is a team-scale project and is scoped honestly as such.

Proof IMAXING →Latent space →

Technical writing that argues — definitional pages that own a term

A failure with no name cannot be specified against or bought against — it gets absorbed and filed under bad luck; the highest-leverage page you can publish is the one that names it. The lab writes definitional pages built to a four-part discipline: a definition sharp enough to be testable, a position that states the standard of proof, applications that tie the term to real work, and limitations that keep the name from overreaching — a name that sharp invites overreach, so the boundary is part of the page. You get a publishable definitional page: the named idea, its standard of proof, its applications and stated limits — writing designed to be cited, with external sources wired in where the public record carries the numbers.

Proof The counterfeit-code note →

Start a conversation

One email with the problem as you understand it is enough. You will get back either a plan or the reasons there should not be one — both are useful.

[email protected]