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:
- OPCODE_ID — a stable name for the procedure.
- INPUT CONTRACT — required and optional inputs.
- EXECUTION BOUNDARIES — defaults, overrides, immutable limits, and precedence.
- OPERATING PROCEDURE — the ordered expert method.
- 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