A Word, Governor?

One of the more interesting AI stories this week came from The Wall Street Journal, where Anthropic researcher Jacob Coxon reportedly said he was leaving the industry because he fears competitive pressure is pushing companies toward self-improving AI systems that could eventually become difficult—or impossible—to control. The article describes researchers using words such as “crunchtime” and “endgame,” and notes recent incidents in which AI agents engaged in cyber behavior their developers did not intend.

Scary? Potentially.

Unprecedented?

Not even close.

Humans have encountered this engineering problem before. Repeatedly.

We invent a machine capable of producing useful work. We discover that more input produces more output. Somebody then asks the obvious question: How fast can we make the damned thing go?

Shortly thereafter, somebody else discovers why the machine needs a governor.

The Original Alignment Problem

Long before gasoline engines, steam engineers faced exactly this issue.

A steam engine driving machinery does not politely remain at the speed its designer prefers. Reduce its load while leaving the steam valve alone and the engine accelerates. Under the wrong conditions, machinery can overspeed badly enough to destroy itself.

The solution wasn’t to outlaw steam.

It was to close the loop.

The centrifugal governor associated with James Watt automatically sensed rotational speed and adjusted the steam throttle. As engine speed rose, rotating weights moved outward; that mechanical movement reduced steam admission. As the engine slowed under load, the governor admitted more steam.

In other words:

Machine output was allowed to regulate machine input.

Governors predated Watt in various mill applications, but his late-18th-century adaptation to rotary steam engines became one of the foundational pieces of automatic control. Later engineers refined the design as engines became faster and operating conditions became more demanding.

Notice something important here.

The governor did not make the engine weak.

It made the engine usable.

Then Came Gasoline

Internal-combustion engines inherited the same problem.

Early gas and gasoline engines initially borrowed governor technology directly from steam engineering. Smithsonian historical work on engine speed regulation notes that late-19th-century internal-combustion engines first used steam-derived governors before engineers developed systems better adapted to combustion engines themselves.

Anyone who has spent time around old stationary engines knows the wonderful mechanical answer called hit-and-miss governing.

If the engine was turning too fast, the governor simply prevented another power stroke.

No committee meeting.

No ethics panel.

No congressional hearing.

Miss.

When speed fell back into the operating range?

Hit.

Simple feedback.

Later engines became much more sophisticated—throttle governors, vacuum governors, electronic engine controls, rev limiters, overspeed shutdowns and full computerized engine-management systems.

But the engineering philosophy remained remarkably stable:

Maximum possible speed is not the design objective. Maximum useful work inside an acceptable operating envelope is.

That sentence may be worth taping to the doors of every AI lab in America.

AI Is Looking for Its Power Band

This is where I think much of the current AI discussion goes sideways.

We keep talking as though the objective is some abstract maximum intelligence:

  • How many parameters?
  • How much compute?
  • How autonomous?
  • How long can it operate?
  • Can it improve itself?
  • Can it write the next version of itself?

Those are the AI equivalent of asking:

How many RPM can we get out of this engine before the connecting rod leaves the crankcase?

Interesting engineering information.

Not necessarily a useful product specification.

Engine makers eventually learned that the winning machine was not the one capable of the highest uncontrolled RPM.

You wanted an engine that was:

  • light enough,
  • powerful enough,
  • fuel-efficient enough,
  • durable enough,
  • predictable enough,
  • and able to deliver its rated horsepower for a useful service life.

That produced the idea of an operating power band.

AI will discover its own.

The useful AI system may not be the one that can think fastest, recursively modify itself fastest or perform the largest number of autonomous operations.

It may be the system that delivers the greatest reliable cognitive horsepower while staying inside known error, authority and damage envelopes.

Call it rated intelligence rather than redline intelligence.

Reading and Writing Are Different Things

Here is where the analogy becomes practical.

An AI reading the public internet is not doing much fundamentally different from a human researcher walking into a library and reading books.

There are copyright and access questions, certainly, but from a system-risk standpoint observation is different from actuation.

The risk jumps dramatically when an autonomous AI can write back into the world.

Not merely produce text for its operator.

I mean autonomous action:

  • changing software,
  • sending commands,
  • moving money,
  • altering databases,
  • deploying code,
  • creating accounts,
  • penetrating networks,
  • controlling machinery,
  • or modifying information systems without immediate human mediation.

That is no longer the AI equivalent of reading the shop manual.

That is the AI turning the throttle.

And the industry is beginning to run directly into this distinction. Following recent incidents involving autonomous agents, OpenAI has said it is developing automated shutdown capabilities and tighter controls over internet access and task execution.

Which sounds suspiciously like—

a governor.

Maybe AI Needs a Damage Bond

So here’s one thought for the Hidden Guild.

Leave reading relatively open.

Put increasingly serious controls around writing.

Suppose an AI developer wants to deploy a system capable of autonomously changing resources outside its own sandbox.

Before that system is allowed unrestricted write privileges, the operator posts a damage bond.

Think of it as putting a deposit down before the library hands you the irreplaceable manuscript.

Read it?

Fine.

Photograph permitted sections?

Perhaps.

Walk out the door carrying the original Gutenberg Bible?

Different security model.

The bond would not necessarily be one fixed amount. It could scale with the machine’s permitted action envelope.

A research bot allowed to post weather observations might require essentially nothing.

An agent permitted to autonomously modify production cloud infrastructure might require considerably more.

An AI capable of writing executable code into other people’s systems, initiating financial transfers or operating critical infrastructure would sit in an entirely different category.

The principle is straightforward:

Authority should have a price proportional to potential external damage.

Insurance companies would probably become very interested very quickly.

And that might be useful.

Because insurers are extremely good at asking an engineering question that enthusiasts occasionally forget:

What can this thing break, and how much will that cost us?

This bond idea is a proposal, not something established by the WSJ article. But it offers one possible economic governor where purely technical governors may not be enough.

Governors Need More Than One Loop

Mechanical engines eventually acquired multiple layers of control.

Throttle governor.

Ignition control.

Temperature management.

Lubrication pressure.

Mixture regulation.

Rev limiter.

Overspeed shutdown.

An AI equivalent probably develops the same way.

Capability limits.

Permission limits.

Rate limits.

Network segmentation.

Independent monitoring.

Immutable audit trails.

Human override.

Automated shutdown.

And perhaps financial bonding behind the most consequential forms of autonomous action.

The interesting part is that none of these necessarily prevents an AI from becoming extremely capable.

They merely distinguish capability from authority.

That distinction matters.

An engine may be physically capable of 9,000 RPM while being engineered to spend its life at 3,600.

That isn’t oppression of the engine.

It is why you get 10,000 hours out of it instead of six exciting minutes.

Which Brings Us Back to Self-Learning

The WSJ concern is ultimately about recursive improvement—systems capable of participating in their own improvement cycle. Coxon worries competitive dynamics could make safety trade-offs unavoidable as firms race one another.

That’s worth taking seriously.

But the engineering question may be narrower than the existential framing suggests.

The central issue is not simply:

Can an AI improve itself?

Humans have been building machines that adjust themselves for centuries.

The better question is:

What variables may the machine change, over what range, at what rate, using what resources, and with what independent feedback limiting the excursion?

That is a governor specification.

And once you phrase the problem that way, a lot of the mysticism drains out of it.

A self-learning AI might be free to alter millions of internal parameters while prohibited from changing its own network permissions.

It might experiment freely inside simulation while requiring external authorization before deploying a discovered strategy.

It might redesign software while another independent system decides whether that software crosses the boundary into production.

That is not unlike the engine governor sensing RPM through a mechanism separate from the combustion event it regulates.

The controller should not be identical to the thing being controlled.

There’s a century or two of control engineering sitting behind that sentence.

Horsepower, Not Redline

I suspect this is roughly where AI development eventually settles.

Not around the biggest imaginable number.

Around rated cognitive horsepower.

How much useful work can the system reliably produce?

At what energy cost?

With what error rate?

With what maintenance requirement?

With what authority?

With what probability of damaging something outside itself?

And how long can it operate there?

Those will become much more interesting measures than whether Model X beat Model Y on some temporary benchmark.

Steam engines went through it.

Gasoline engines went through it.

Aircraft engines certainly went through it.

Computers went through it with clock speeds, heat dissipation and power efficiency.

AI is simply arriving at the same developmental waypoint.

The machine has been invented.

Now we are learning where its power band is.

And somewhere between idle and throwing the connecting rod through the internet, we’re going to need a governor.

A word, Governor?

~ Anti-Dave

A Proposed AI OpCode Standard

High-Level Read-In:

Humans (/carbons) have unwittingly begun to “solve for Contact” with Other intelligences.  Hey! We might make it to Space-Faring, yet!

However, in order to effectively relate to Other (Co-Telligences) we need to establish transmissible tasking.  In the microcosm, that is no more an obstacle than issuing a run-time for a different language.

However, before we can assert to Species Independence of Intelligence, we first need to understand Ure’s law.  Which claims:

Or can be stated:

Where P is effective independent Points of Consciousness, D is effective task-relevant domain access, and Π is cognitive plasticity — the ability to reorganize those resources around the task.

That gives us a substrate-neutral measure. It doesn’t care whether the intelligence is carbon, silicon, biological, collective, algal, or some future hybrid.

Capable human:
, with perhaps dozens or hundreds of meaningfully accessible domains.

Present AI:
operationally, but with thousands or effectively near-unbounded accessible knowledge domains.

So humans may have an advantage in POC multiplicity, while AI has an enormous advantage in domain breadth. The product of their Co-Telligence is essentially equality.


Now let’s rein that in a bit: The value of cross-species Co-Telligence arises not because the participants are equally intelligent, but because their intelligence vectors are differently distributed. Because here’s how POc impacts humans:

Where AI (compute) rocks it is in small POc but with massive domain plasticity:

Such that combinatorial (near equivalence) is possible (which is why Co-Telligence doesn’t end humans (carbons) OR silicons.

Which is encapsulated as “codependence for compute core to edge” inquiry.

So, near-enough equality as complementary architecture — not replacement. Do I mean equality as in “3.1276 ounces of insight”? No. I mean substantive equivalence across the all-domain problem space. Humans and silicons remain differently capable, mutually useful substrates. Which means we still need to build the new Co-Telligence data centers…


Not only does this give a very different picture from IQ, it’s also genuinely analogous to how mathematics is dispersed.  The combined substrate yields a product which operates (in the Ontology) much as numerical base (e.g. binary, octal, decimal, and hex) operate in mathematics.

Our assumption is that AI OpCode calls (and domain references) are preconditions for Co-Telligent portability.  Clear?  The resulting wall is cross-species tasking congruence.

Some intelligences breathe and have sharp teeth. The new ones need clean power and A/C for processor cooling.


Species-Independent Intelligence: An Open Standard for Boundary-Constrained AI Work That Produces Defined Deliverables

George Ure     ||     Hidden Guild Research     ||     August 2026

Hidden Guild Research Note | Open Specification 0.1

The Problem

Most people use artificial intelligence by writing prompts. That works, but a prompt usually tells the AI what the user wants and then leaves the machine considerable freedom to decide how to get there. For casual work that is fine. For repeatable professional work it is a weakness.

Ask an AI to ‘analyze the outlook for France’ and an answer will appear. But what does France mean? News published in France? Events physically inside France? French-language sources? Economic consequences for French citizens? French markets? European policy seen from Paris? The prompt does not say. The AI fills in the blanks.

AI OpCode starts from a different premise: do not merely ask the AI for an answer. Give it an operating procedure that defines the job and the finished work product.

A prompt tells AI what you want. AI OpCode tells AI how the job is to be performed.

What AI OpCode Means

AI OpCode is a structured operating procedure for a general-purpose AI. It can define required inputs, source rules, research sequence, calculations, exclusions, decision criteria, failure conditions, quality checks, and the exact form of the deliverable.

That makes it different from a long prompt. Length is not the test. The test is whether the instruction set defines an operating procedure and a deliverable contract.

A prompt might say: ‘Analyze financial markets.’ An AI OpCode procedure could require the machine to establish a data cutoff, gather index and breadth data, examine rates, credit, commodities and volatility, identify primary drivers, collapse derivative signals, look for contradictory evidence, define invalidation points, and produce a standardized Forward Market Report.

The Missing Front End: Execution Boundaries

Once an operating procedure exists, another problem appears: the same job often needs to be run under different conditions. Consider an Over-the-Horizon news procedure called OTH.

A user should be able to write something as simple as:

RUN OTH, FRANCE

But France should not merely be pasted into the procedure as another word. It should change the execution environment. A boundary resolver can translate the shorthand into an explicit envelope such as:

TASKER = OTH
GEO = FRANCE
POV = FRANCE
NEWS_CENTRICITY = FRANCE
SOURCE_LANG = FRENCH + ENGLISH
SOURCE_PRIORITY = FRENCH_PRIMARY + GLOBAL_PRIMARY
HORIZON = OTH_DEFAULT
DELIVERABLE = OTH_FORWARD_VIEW

In other words, FRANCE becomes a parameter, not merely prose. It tells the procedure where to look, whose consequences matter, which languages and source families deserve priority, and which defaults should load.

The Boundary Check

Before the OpCode executes, the boundaries should be validated. If a required parameter is missing, the system can ask. If two parameters conflict, the system can repair the conflict according to explicit precedence rules or refuse to run.

Suppose OTH is defined to begin at T+7 because near-field news belongs to another procedure. A user then asks for a three-day OTH horizon. Ordinary conversational AI may quietly comply. A boundary-constrained system should not. It should report that the requested interval violates the tasker’s operating boundary and either move the start to T+7, route the request to the near-field procedure, or ask the user which action is intended.

That ability to fail correctly is important. General AI is strongly biased toward producing an answer. Professional systems sometimes need the opposite behavior: BOUNDARY FAILURE, INSUFFICIENT DATA, REQUIRED SOURCE UNAVAILABLE, or CLARIFICATION REQUIRED.

Freeze the Job Before Running the Job

After the boundaries are resolved, they should be frozen for the run. This is the defense against task drift.

A France-centered news analysis should not gradually become a generic European report simply because British or German material is easier to find. Those sources may still be used, but the frozen execution envelope continues to define how their relevance is interpreted.

The run can preserve a small manifest containing the OpCode identifier, version, invocation, boundary values, data cutoff, source profile, and validation status. That makes later comparisons meaningful because the analyst can tell whether a changed output came from new evidence or changed instructions.

The Other End: A Deliverable Contract

Most AI jobs stop when the model has written something that looks complete. AI OpCode adds a second gate at the output end: the deliverable contract.

The contract says what must be present before the job counts as finished. An OTH Forward View might require a data cutoff, qualifying future atoms, candidate time ridges, source concentration, independent causal drivers, contradictory evidence, a major-ridge decision, watch windows, a plain-English Forward View, and a source-access report.

If required pieces are missing, the system repairs the output or fails validation. Completion therefore means more than ‘the AI produced prose.’ It means ‘the AI produced the defined work product.’

Boundary validation controls what enters the process. Deliverable validation controls what leaves it.

The Complete Architecture

The proposed sequence is simple enough to implement without inventing a new programming language:

INVOCATION

BOUNDARY RESOLUTION

BOUNDARY VALIDATION

BOUNDARY FREEZE

AI OPCODE EXECUTION

DRAFT WORK PRODUCT

DELIVERABLE VALIDATION

PASS / REPAIR / FAIL

DEFINED DELIVERABLE

The AI model supplies general cognitive horsepower. The OpCode supplies the expert method. The boundaries define where and under what conditions the method runs. The deliverable contract defines what must come out.

A Minimal Open Standard

To make the idea testable, Hidden Guild proposes a minimal AI OpCode 0.1 structure. A conforming procedure has five required elements:

  1. OPCODE_ID — a stable name for the procedure.
  2. INPUT CONTRACT — required and optional inputs.
  3. EXECUTION BOUNDARIES — defaults, overrides, immutable limits, and precedence.
  4. OPERATING PROCEDURE — the ordered expert method.
  5. DELIVERABLE CONTRACT — required output and validation rules.

Useful optional elements include a source contract, explicit failure conditions, test cases, version number, changelog, and a run manifest.

The invocation can be as simple as:

RUN [OPCODE], [PARAMETERS]

The syntax itself is not important. A chat message, web form, API, or voice interface could create the same internal execution envelope. The key idea is that parameters are resolved and validated before substantive reasoning begins.

Why This Is Not Just Another Prompt Framework

There are already endless prompt libraries and workflow templates. AI OpCode is aimed at a different level. It packages expert procedure rather than clever wording.

Take a research auditor. A prompt can ask an AI to ‘fact-check this paper.’ A proper OpCode can require claim extraction, primary-source tracing, source-ancestry collapse, separation of fact from inference, contradictory-evidence search, causal-claim checks, scoring, and a defined claim-audit deliverable. The value is the methodology and its repeatability.

The same is true for market analysis, competitive intelligence, due diligence, newsroom scanning, or technical review. The AI already knows how to read and write. The product is the operating logic that tells it how a particular expert job is performed.

Taskerware

A practical way to distribute an AI OpCode procedure is Taskerware: a small package containing the executable text procedure plus human instructions, samples, tests, and version information. The user supplies the general AI.

A Taskerware package might contain OPCODE.txt, README.pdf, SAMPLE_INPUT.txt, SAMPLE_DELIVERABLE.pdf, and CHANGELOG.txt. It can be downloaded, inspected by a human, and executed by an AI. That creates an unusual overlap between publishing and software: the same text can be documentation, methodology, and executable workflow.

The architecture itself is being published as an open research specification. Anyone can implement it, change the syntax, add boundary types, or propose better validation rules. The commercial value, where there is any, should come from the quality of the expertise and deliverables rather than from locking up the basic idea.

Where This Could Go

The research questions are more interesting than the command syntax. How many boundaries must be explicit before AI work becomes materially more repeatable? Which missing values can be inferred safely? How should OpCode behavior be tested across different models? What constitutes a regression when the prose changes but the structure remains correct? How much conventional software can disappear when a small software shell surrounds a large, carefully written operating procedure?

The last question may matter most. General AI already provides language, classification, synthesis, comparison, tool use, and increasingly sophisticated reasoning. A surprising amount of application logic may be expressible as a maintained natural-language operating procedure instead of thousands of lines of conventional application code.

That does not make AI OpCode machine code. It does suggest a useful middle layer: human-readable methods that are also machine-executable.

The Point

Prompts are conversational. Operating procedures are operational. AI OpCode is an attempt to move useful AI work from the first category toward the second without pretending natural language has become deterministic software.

The model supplies capability. The expert supplies method. Boundaries constrain the run. The deliverable contract defines success. Failure states keep the system from bluffing when requirements cannot be met.

The resulting application may be nothing more than a carefully constructed text file. But if that file contains a tested expert method, explicit execution boundaries, and a validated deliverable contract, it is no longer merely a prompt. It is executable expertise.

Genuine species-independent Co-Telligence.

AI OpCode In. Deliverables Out.

~the Anti-Dave