{ "updated": "2026-10-20", "invitation": "This programme needs people who can show it where it is wrong, and it is built to publish what they find. There are three ways in: a core research role, a defined piece of contract work, or an advisory review at a prepared point. None asks you to accept the theory: a precise contribution is worth making whatever its verdict.", "intro": "The question above is open, and the programme is built to test it rather than assume the answer. Its laws are stated as predictions that could fail, no new study runs until its registration is public, and the corrections are published beside the papers. The roles below bring the specialist judgement the next stage needs: measurements that can tell a real effect from an artefact, software another team can rerun, scrutiny before a finding becomes a claim, and judgement about how institutions would use what is found. Several are bounded contributions rather than jobs: a review at the point where it can still change the design, a defined piece of software, or a critique of one use case.", "intro_links": [ { "label": "The papers", "href": "/research/papers/" }, { "label": "The registered tests", "href": "/research/registered-programme/" }, { "label": "The corrections", "href": "/research/corrections/" } ], "routes": [ { "id": "core", "title": "Core research roles", "text": "Planned posts, subject to funding, with day-to-day responsibility for the science, the software, the delivery and the money.", "roles": [ "research-scientist", "lead-research-engineer", "project-administrator", "finance-lead" ] }, { "id": "contract", "title": "Defined contract work", "text": "A bounded piece of work with a fixed deliverable: a replication run by a separate team once the protocol and the software are fixed, or a licence review of a defined release. Each is agreed in writing, with its fee, before it starts.", "roles": [ "replication-partner", "licence-reviewer" ] }, { "id": "advisory", "title": "Advisory and external review", "text": "Prepared reviews at the points where they can still change the work: before a design is frozen, before a run, and before a finding is published. Advisers keep their independence of view, may publish their own assessment and are not asked to endorse the theory. Time is modest and stated, compensation is set out in writing before any invitation, and no route depends on unpaid review.", "roles": [ "senior-methodology-adviser", "dynamical-systems-adviser", "security-cryptography-adviser", "institutional-governance-adviser", "market-infrastructure-adviser" ] } ], "conditional_scope": { "title": "A conditional engineering scope", "text": "Four engineering roles belong to a larger engineering scope: an open component for agents that act for different owners. They would start only if that scope is funded, and they are shown after the three routes for that reason.", "roles": [ "security-technical-lead", "formal-methods-researcher", "senior-research-software-engineer", "systems-integration-engineer" ] }, "board": { "title": "A founding Scientific Advisory Board (planned)", "status": "Planned · No members appointed", "text": "The board's first members would establish it. Each would hold a stated remit, statistical methodology among them, give a modest and stated amount of time, keep full independence of view, and receive written terms, compensation included, before accepting. Membership carries no co-founder status and no endorsement of the programme's claims. A lighter route stays open: an individual adviser on one question. No member is named until an appointment is accepted." }, "contact": { "label": "Start a conversation", "href": "/contact/", "text": "Say which route interests you. A first conversation can start with one question, one review or one defined piece of work." }, "footer": "Planned roles, 20 October 2026. Every planned role below the founder is unfilled, no advisory board member is appointed, and no advisory or institutional relationship is announced. Funded roles depend on funding; advisory contributions depend on the contributor's agreement and, where it applies, their employer's. No role requires agreement with the theory.", "labels": { "responsibilities": "The work", "output": "First output", "experience": "Experience sought", "opportunity": "What you could shape", "commitment": "Time and arrangement", "details": "The work, experience and time", "decides": "Decision rights, proposed and agreed on appointment" }, "sections": [ { "id": "delivery", "title": "Research and delivery", "intro": "The delivery team turns a registered question into a test that runs, is checked, and can be understood by someone outside the team. Each part has one owner: the science, the software, the delivery and the money." }, { "id": "engineering", "title": "Engineering for agents acting across organisations", "intro": "A larger engineering scope would build an open component for agents that act for different owners: a check at the point where an action takes effect, made against written rules, with a record another party can verify. These roles belong to that scope and would start only if it is funded." }, { "id": "advisory", "title": "Methods and external scrutiny", "intro": "Experienced reviewers change most at a few prepared points: before a design is frozen, before a run, and before a finding is published. Replication comes from a separate team after the design and the software are fixed, so that it tests the work rather than repeats it." }, { "id": "governance", "title": "Institutions and practical use", "intro": "Research on delegation has to meet the obligations that people and institutions actually carry. These advisers would test the programme's questions against real mandates, real counterparties and the routes by which institutions accept new arrangements." } ], "roles": [ { "id": "research-scientist", "section": "delivery", "title": "Research scientist, measurement and statistics", "status": "Core role · Planned · Unfilled · Subject to funding", "purpose": "Design studies that can tell a genuine change in how a system corrects itself from a change in compute, information or scoring.", "opportunity": "Shape the measurements that make an open question answerable, so that a result counts whichever way it falls.", "responsibilities": [ "Define what each study measures, what it is compared with, and the result that would change the conclusion, before any data exist.", "Size each study with design simulations, and fix in advance how dependent, missing or unusable replies are treated.", "Lead the day-to-day research, including the task populations and counted tests, and report analyses another researcher can rerun." ], "output": "A registration-ready analysis plan, with its design-simulation record and a specification of how the results will be reported.", "experience": "A doctorate or equivalent experience in statistics, experimental design or machine-learning evaluation, including simulation-based sizing and sequential decisions.", "commitment": "Most of a working week from the start of funded work, responsible for the day-to-day science.", "route": "core", "decides": "Would own each study's statistical analysis plan and sign it before the design is frozen, and could hold a run until a measurement problem is resolved." }, { "id": "lead-research-engineer", "section": "delivery", "title": "Lead research engineer, evaluation software", "status": "Core part-time role · Planned · Unfilled · Subject to funding", "purpose": "Build the software that runs each test exactly as registered and makes every count traceable to the rule that produced it.", "opportunity": "Build evaluation software that other teams can inspect, rerun and extend, joining statistical care to production engineering.", "responsibilities": [ "Own the evaluation harness, the model interfaces, the counting code and the implementation of the registered analysis.", "Record versions, spend, failed calls and every departure from protocol, so that a silent failure cannot pass as a result.", "Package the commands, pinned dependencies and evidence that a separate team needs to reproduce the work." ], "output": "A tested, versioned run package, with a path a reader can follow from each registered rule to each reported count.", "experience": "Production Python and a memory-safe systems language, research software, model APIs and statistical computing.", "commitment": "Part-time on agreed milestones, starting once a design is approved for building, and working with the research scientist and the methodology adviser.", "route": "core", "decides": "Would decide the evaluation software's architecture and could refuse to release a version that fails its own tests." }, { "id": "project-administrator", "section": "delivery", "title": "Research delivery and document control", "status": "Core part-time role · Planned · Unfilled · Subject to funding", "purpose": "Keep the work on schedule, and make every commitment, deadline and required document visible to the person who owns it.", "opportunity": "Give a small research team the operating discipline that lets it spend its attention on the work only it can do.", "responsibilities": [ "Keep the milestone schedule, the meeting actions and the project records current.", "Prepare the checklist and the document set for each registered run, with approvals and versions kept together.", "Track dependencies, and book reviews early enough for their findings to change the work." ], "output": "A live delivery calendar, and a complete document set for the first registered run.", "experience": "Research or technical project coordination, document control and dependable follow-through.", "commitment": "Part-time from the start of funded work.", "route": "core", "decides": "Would own the delivery schedule and the document record, and could hold a deposit or a release whose records are incomplete." }, { "id": "finance-lead", "section": "delivery", "title": "Finance lead", "status": "Core role · Planned · Unfilled · Subject to funding", "purpose": "Give the programme an exact account of its money, its commitments and its ability to finish what it starts.", "opportunity": "Build financial control into a young research organisation from its first month, so that ambitious work stays accountable.", "responsibilities": [ "Run the ledger, payroll, procurement, supplier payments and monthly reconciliations.", "Keep a rolling thirteen-week cash forecast, and match every claim and payment to its evidence.", "Report spending, commitments and delivery risk in a short monthly note, and prepare the records the external auditor needs." ], "output": "A working ledger, a cash forecast and a monthly reporting pack with its supporting records.", "experience": "A qualified accountant with hands-on financial control in a small organisation.", "commitment": "From the first month, with time set by the funded scope; reporting to the founder, and separate from the external auditor.", "route": "core", "decides": "Would approve spending against the budget and sign the financial reports, separately from the external auditor." }, { "id": "security-technical-lead", "section": "engineering", "title": "Technical lead, security engineering", "status": "Core role, conditional engineering scope · Planned · Unfilled · Starts only if that scope is funded", "purpose": "Lead the engineering of a check that decides whether an agent's action takes effect, and of the record that lets another party verify the decision.", "opportunity": "Set the security design of an open component while its threat model and trust boundaries are still being decided.", "responsibilities": [ "Write and maintain the threat model, and the trust boundaries between the agents, their owners and the check.", "Lead the design and review of the gate, and of the broker that carries actions across those boundaries.", "Hold authority over engineering decisions, and run the weekly engineering cycle." ], "output": "A written threat model and a reviewed design for the gate and its record.", "experience": "Senior security engineering, threat modelling, and the design of systems that enforce policy at a boundary.", "commitment": "Full-time technical leadership within the engineering scope.", "route": "conditional", "decides": "Would set the engineering scope's threat model and security architecture, and could stop a release with an open security finding." }, { "id": "formal-methods-researcher", "section": "engineering", "title": "Formal-methods researcher", "status": "Core role, conditional engineering scope · Planned · Unfilled · Starts only if that scope is funded", "purpose": "State precisely what the component guarantees, and check those guarantees with machine-checked models.", "opportunity": "Make the component's claims exact enough to be proved or refuted, and show where the implementation and the specification part.", "responsibilities": [ "Write the specification of the protocol's properties.", "Build machine-checked models of those properties, and check the implementation's state machine against them.", "Report each property that does not hold, with the case that breaks it." ], "output": "A specification and machine-checked models, with a record of which properties hold and which do not.", "experience": "Formal specification and machine-checked proof or model checking, applied to protocols or distributed systems.", "commitment": "Full-time within the engineering scope.", "route": "conditional", "decides": "Would decide which properties are specified and proved, and would state in each release what a proof covers and what it does not." }, { "id": "senior-research-software-engineer", "section": "engineering", "title": "Senior research software engineer, reference implementation", "status": "Core role, conditional engineering scope · Planned · Unfilled · Starts only if that scope is funded", "purpose": "Build the open reference implementation: the component itself, its record store and the verifier another party runs.", "opportunity": "Write the code that others will read to learn what the component does, and that a verifier can check without trusting its authors.", "responsibilities": [ "Implement the component, its record store and its verifier to the specification.", "Test every path that can allow, hold or refuse an action, including failure and recovery.", "Publish each release with its tests, pinned dependencies and documentation." ], "output": "A first tagged release of the reference implementation, with its tests and a verifier that runs on its own.", "experience": "Senior research or production software engineering, testing, and secure, reproducible release practice.", "commitment": "Full-time within the engineering scope.", "route": "conditional", "decides": "Would set the reference implementation's design and its code-review standard." }, { "id": "systems-integration-engineer", "section": "engineering", "title": "Systems and integration engineer", "status": "Core role, conditional engineering scope · Planned · Unfilled · Starts only if that scope is funded", "purpose": "Connect the component to the agents, workflows and environments in which it would actually be used.", "opportunity": "Turn a verified design into something other teams can adopt, by making it work inside their systems.", "responsibilities": [ "Build the adapters that connect agents and workflows to the component.", "Deploy the reference implementation and keep each deployment reproducible.", "Integrate it with shared evaluation environments, and document what each integration covers and what it does not." ], "output": "Working adapters for representative workflows, with deployment and integration documentation.", "experience": "Systems engineering, integration of services and agents, deployment and reproducible infrastructure.", "commitment": "Full-time within the engineering scope.", "route": "conditional", "decides": "Would set the integration interfaces and the test environments used with outside systems." }, { "id": "senior-methodology-adviser", "section": "advisory", "title": "Senior adviser, empirical methodology", "status": "Advisory review · Proposed · To be invited · Subject to agreement", "purpose": "Judge whether a proposed evaluation can answer its question, and challenge the interpretation before a finding becomes a public claim.", "opportunity": "Bring judgement earned in demanding real-world validation to an open question in AI, at the few points where it changes the outcome.", "responsibilities": [ "Review the experimental contrast, the accounting for compute, what each system may see and do, and the treatment of noisy scores and unusable replies.", "Set methodological priorities for the delivery team at the protocol, pre-run, results and publication reviews.", "Name the alternative explanations, and the limits on carrying a bounded result over to the wider theoretical question." ], "output_label": "Contribution sought", "output": "A written methodological review: the controls agreed, the questions left open and the changes required before the first run.", "experience": "Senior experience in empirical machine-learning evaluation, uncertainty and statistical design, or in validating models where errors are costly.", "commitment": "A small number of prepared reviews across the project; building and routine analysis stay with the delivery team. Any formal role would be agreed with the contributor and, where required, their employer.", "route": "advisory", "decides": "Would advise on designs, power and analysis plans before they are frozen; a written objection would be answered in writing and published with the design." }, { "id": "dynamical-systems-adviser", "section": "advisory", "title": "Adviser, dynamical systems and control", "status": "Advisory review · Proposed · To be invited · Subject to agreement", "purpose": "Test the mathematics of the theory: its assumptions, its derivations, and how its quantities map onto things that can be measured.", "opportunity": "Examine a theory while part of its mathematics is still in development, when a precise objection can change what it claims.", "responsibilities": [ "Critique the assumptions and derivations behind the theory's laws, including the two whose mathematics is still in development.", "Assess which of the theory's parameters the planned measurements could identify.", "Mark where a bounded task experiment does and does not bear on the theory's wider claims." ], "output_label": "Contribution sought", "output": "A written mathematical review of the laws, their identifiability and their mapping to measurement.", "experience": "Dynamical systems, control theory or applied mathematics, with experience of connecting models to data.", "commitment": "Focused review of prepared material at agreed points.", "route": "advisory", "decides": "Would advise on the models and derivations at agreed points; a written objection would be answered in writing and published with the paper." }, { "id": "security-cryptography-adviser", "section": "advisory", "title": "Adviser, agent security and cryptography", "status": "Advisory review · Proposed · To be invited · Subject to agreement", "purpose": "Challenge the threat model, the trust boundaries, and the relation between a proof, a policy and the action being accepted.", "opportunity": "Shape how evidence about an agent's action is bound to that action, while the design can still take the advice.", "responsibilities": [ "Review the threat model and the trust boundaries at each engineering milestone.", "Assess what the records prove, to whom, and under which assumptions.", "Identify where established cryptographic and verification methods should be used in place of new mechanisms." ], "output_label": "Contribution sought", "output": "Written milestone reviews of the threat model and the record design.", "experience": "Senior work in security engineering, applied cryptography or formal verification.", "commitment": "Milestone reviews of prepared material.", "route": "advisory", "decides": "Would advise on the engineering scope's threat model and protocols; a written objection would be answered in writing before the next milestone." }, { "id": "replication-partner", "section": "advisory", "title": "Separately operated replication", "status": "Defined contract · Planned · Partner sought · Subject to funding", "purpose": "Establish what another team can reproduce from the frozen protocol and the released package.", "opportunity": "Produce evidence that stays useful whether the original result holds, changes or fails to reproduce.", "responsibilities": [ "Run the released package on separately operated infrastructure and provider accounts.", "Record environmental differences, missing instructions and every discrepancy in running or in results.", "Report agreement and disagreement under rules agreed before the repeat." ], "output": "A reproduction record stating what was run, what differed, and which conclusions the repeat supports.", "experience": "Model evaluation and reproducible research. The team must not have written the software it reproduces.", "commitment": "A defined external piece of work, once the protocol and the software are fixed.", "route": "contract", "decides": "Would run the fixed protocol separately and publish its own results in its own words, whatever they show; the programme would have no veto." }, { "id": "licence-reviewer", "section": "advisory", "title": "Licence review for research software", "status": "Defined contract · Planned · Reviewer sought · Subject to funding", "purpose": "Make the rights and dependencies of each software release clear enough for others to build on it.", "opportunity": "Remove the practical obstacles between a research release and its legitimate use by other teams.", "responsibilities": [ "Review the release's dependencies, notices and proposed licence terms.", "Separate the project's outputs from existing proprietary code and third-party material.", "Find and resolve licence conflicts before release." ], "output": "A review of one release's dependencies and licences, listing the required notices and any remaining restrictions.", "experience": "Software licensing, dependency compliance and open release practice.", "commitment": "A bounded review of a defined release.", "route": "contract", "decides": "Would decide whether a release's licences and third-party terms are in order, and could hold the release until they are." }, { "id": "institutional-governance-adviser", "section": "governance", "title": "Senior adviser, international institutional governance", "status": "Advisory review · Proposed · To be invited · Subject to agreement", "purpose": "Examine how authority, accountability and cooperation would work once organisations delegate decisions to systems of growing capability.", "opportunity": "Apply experience of making international institutions work to arrangements that are still open to change.", "responsibilities": [ "Read proposed uses of the research against institutional mandates, delegated powers and acceptance between parties with different interests.", "Challenge who decides, who oversees, and how disagreements are resolved.", "In later governance work, review the draft HARI Treaty (Hardware-Aligned Recursive Intelligence) instruments for institutional feasibility, representation and implementation." ], "output_label": "Contribution sought", "output": "A short critique of institutional feasibility, naming the assumptions, responsibilities and practical questions that need more work.", "experience": "Senior experience of international institutions: their governance, their accountability, and cooperation across borders.", "commitment": "Focused conversations and review of prepared material. Any formal role would be agreed with the contributor and, where required, their employer.", "route": "advisory", "decides": "Would advise where the programme's questions meet real institutional mandates; a written objection would be answered in writing." }, { "id": "market-infrastructure-adviser", "section": "governance", "title": "Senior adviser, financial market infrastructure and counterparty risk", "status": "Advisory review · Proposed · To be invited · Subject to agreement", "purpose": "Test whether the programme's account of delegated work matches the obligations and risks that real counterparties carry.", "opportunity": "Bring experience of market standards and institutional trust to the question of how parties accept work done by autonomous agents.", "responsibilities": [ "Supply realistic cases involving mandates, acceptance conditions, confirmation, settlement and disputed performance.", "Challenge the incentive assumptions, and separate a local operational failure from a potentially systemic one.", "Judge what evidence an organisation would need before it relied on the outputs." ], "output_label": "Contribution sought", "output": "A critique of one proposed use case: the obligations, the ways it could fail, and the questions adoption would raise.", "experience": "Senior financial-markets experience across counterparty obligations, market infrastructure or common standards.", "commitment": "Prepared discussions at agreed intervals, with no operational role.", "route": "advisory", "decides": "Would advise on counterparty and settlement risk in the use cases; a written objection would be answered in writing." } ] }