Beyond agents. Governed digital work.
A human-readable design language for the hybrid workforce.
Define the outcome. Bound the authority. Keep accountability human.
Why NOID · The demo · The framework · Trust · Learning · Economics · Explore the files
Your agent can act. Can your organisation explain why it was allowed to?
A prompt can make an agent useful.
A model can make it capable.
Neither makes it governable, sustainable or accountable.
NOID starts where the demo ends.
It gives people a small, inspectable way to describe digital work before a runtime acts: the outcome, the participants, their authority, the human-control relationship, the evidence, the cost boundary and the path for learning and change.
Not another orchestration engine. Not another prompt library. Not another claim that autonomy will somehow manage itself.
NOID is the contract you can put on the table when the technology is exciting but the accountability is still yours.
NOID is a name, not an acronym. It grew out of VirtuallyNoIdea's work on a simple problem: agents are becoming easier to build, but the work around them remains difficult to explain, govern and improve.
The name does not hide a technical expansion. It marks the public framework and the question behind it: what must an organisation make explicit before a digital worker acts?
See the public language reference for the terms used throughout this repository.
| Mistake | What it looks like | What gets missed |
|---|---|---|
| Optimise before defining the outcome | Start with headcount reduction, token price or a list of tasks to automate | Whether the work is worth doing, who owns it and what an accepted result actually is |
| Let the platform become the operating model | Treat the selected vendor, model or agent framework as the AI strategy | Portability, organisational control and the ability to change direction |
| Deploy capability without workforce discipline | Give an agent tools and call it autonomous | Identity, authority, supervision, lifecycle, evidence, cost and controlled improvement |
These are design challenges, not a claim that every organisation behaves the same way. The demo asks whether an agent can complete a task. NOID asks whether the work should happen, who remains accountable, what authority is justified, what it really costs and how it can improve without drifting beyond control.
NOID proposes that a sustainable digital workforce must protect more than short-term efficiency. It must preserve the judgement, resilience and institutional learning the organisation still needs.
A sustainable digital workforce has to work across four dimensions:
| Dimension | The management question |
|---|---|
| Human | Does digital work strengthen human judgement, learning and capacity—or remove the pathway by which people develop them? |
| Economic | Does the route create accepted outcomes at a defensible fully loaded cost, including supervision, assurance and failure? |
| Operational | Can the work survive exceptions, change, incidents, unavailable dependencies and the Monday after the demo? |
| Resource | Are model, compute, data and infrastructure choices proportionate to the work and its consequences? |
The objective is not to maximise autonomy or minimise tokens. It is to build an organisation that can use digital labour without surrendering accountability, adaptability or the ability to learn.
NOID's design position is to select the simplest responsible allocation of people, rules, automation, workflows and digital workers that can produce the accepted outcome.
| If the work is… | Start with… |
|---|---|
| Stable, explicit and deterministic | A rule or ordinary automation |
| Multi-step but predictable | A workflow with visible checks |
| Interpretive but low consequence | A digital assistant preparing work for review |
| Variable and judgement-dependent | A bounded agent with explicit human control |
| Non-delegable, high consequence or insufficiently evidenced | Human judgement |
More agency is not automatically more advanced. It creates more possible paths, more possible failure and more to govern.
The first NOID demo is deliberately ordinary: a fictional bicycle shop needs to review a refund request.
| Participant | Job | Hard boundary |
|---|---|---|
| Refund reviewer | Compares the request with a fictional policy and prepares a recommendation | Cannot issue a refund or contact the customer |
| Evidence checker | Challenges the recommendation and verifies that every claim has a source record | Cannot approve the recommendation or invent missing evidence |
| Service adviser | Reviews the evidence and makes the final decision | Remains accountable for the customer outcome |
| Order register | Supplies the recorded order and return state | Is the system of record—not an agent |
Two simple digital workers. One accountable human. One authoritative service. No digital worker can complete the transaction.
That limitation is the point.
NOID describes a governed outcome as a set of readable, versioned relationships.
The public contract is intentionally small: it exposes essential relationships for challenge before a runtime makes them difficult to see.
NOID does not publish an empty methodology and ask readers to imagine the rest. The public proposition, contract, synthetic proof and trust surfaces are visible as files:
This is the structure intended for the clean public repository:
noid/
├── README.md # Proposition and fastest path in
├── .github/ # Read-only CI and contribution templates
├── docs/
│ ├── concepts/ # Public design explanations
│ ├── reference/ # Glossary, object and repository maps
│ ├── assets/ # Original public diagrams
│ ├── decisions/ # Public-contract decisions
│ └── release/ # Release-integrity requirements
├── spec/ # Human-readable public contract and limits
├── schemas/ # Normative machine-readable work shape
├── templates/ # Non-normative public authoring cards
├── teams/ # Outcome-specific workforce definitions
│ └── harbour-bicycle-refund/
│ ├── work.noid.json # Authoritative v0.1 work definition
│ ├── TEAM.md # Human-readable team card
│ ├── workers/ # Team-bound worker identities
│ ├── skills/ # Team-local capability methods
│ ├── workflows/ # Hand-offs, gates and exceptions
│ └── governance/ # Ownership and decision rights
├── shared/ # Reusable, non-normative references
│ ├── workers/ # Worker-blueprint guidance
│ ├── skills/ # Reusable capability methods
│ ├── tools/ # Controlled interface descriptions
│ ├── workflows/ # Reusable hand-off patterns
│ └── governance/ # Reusable control patterns
├── checks/ # Dependency-free validation and tests
├── GOVERNANCE.md # How the public specification changes
├── SECURITY.md # Reporting and enforcement boundary
├── PROVENANCE.md # Clean-room origin and exclusions
├── LICENSE + LICENSES/ # Proposed licence scopes and legal texts
└── CHANGELOG.md # Contract and candidate history
Teams bind the work. Each team names its outcome, accountable owner, participants, authority, local components, human-control route and evidence.
Shared components support reuse. A team must still bind an exact version,
owner, scope and authority. Shared never means globally trusted or silently
updated. NOID itself remains the framework through spec/, schemas/ and
templates/; it is not duplicated inside each team.
The release-candidate wrapper, private review evidence, protected-source scans and internal promotion controls are not part of that published tree.
NOID uses readable, version-controlled artefacts as the inspectable interface between organisational intent and changing technology. The filesystem is not the intelligence or enforcement layer; it is where people can see purpose, authority, capabilities, human intervention and required evidence even as models, tools and runtimes change.
Digital workers need enough context to do the work, but not every piece of context the organisation owns.
| Layer | Contains | Why it exists |
|---|---|---|
| 0 — Foundation | Purpose, non-negotiables, public boundaries and operating rules | Establishes the conditions no task may silently override |
| 1 — Organisation and crew | Shared objectives, domain context, responsibilities and team relationships | Grounds the worker in the part of the organisation it serves |
| 2 — Worker | Identity, capability, authority, human peer and lifecycle state | Defines who is participating and under what limits |
| 3 — Work package | Outcome, workflow, case context, permitted tools and escalation points | Supplies only what is needed for the current work |
| 4 — Evidence and learning | Sources, decisions, exceptions, outcomes, feedback and approved changes | Makes the work reviewable and improvement governable |
Context inherits downward. Evidence travels upward. Any exception to the declared boundary should be explicit, reviewable and temporary.
One reason agent systems become difficult to govern is that everything gets called an agent. NOID separates the pieces.
| Object | What it is | What it is not |
|---|---|---|
| Outcome | The accepted result the organisation is trying to produce | A task completion or model response |
| Worker | A human, digital worker or authoritative service with a defined responsibility | A synonym for an LLM |
| Capability | A stable unit of ability required by the work | A particular worker, model or product |
| Agent | A model-backed digital worker able to interpret context and make bounded judgements | Automatic authority to act |
| Skill | A reusable way to perform a defined capability | A standing permission |
| Tool | A controlled interface to data or an external system | Proof that the worker may use it now |
| Workflow | A sequence of work, hand-offs, decisions and checks | Necessarily an AI process |
| Framework | A reusable structure for designing, governing or evaluating work | A runtime dependency |
| Work definition | The versioned contract joining outcome, participants, boundaries, control, evidence and lifecycle | A production security control |
| Metadata | The identity, ownership, lineage, scope and state that make every object governable | Decorative documentation |
Metadata should be boring in the best possible way: stable identifiers, version, owner, provenance, sensitivity, permitted scope, dependencies, lifecycle state, evidence expectations and cost classification.
It is what lets a person ask not just “What can this agent do?” but “Which version, for whom, using what, under whose authority, based on which evidence?”
An agent name and a system prompt are not an identity.
NOID uses five questions to make a digital worker's identity reviewable:
| Dimension | Question |
|---|---|
| Purpose | Why do I exist, and which outcome am I here to support? |
| Capability | What can I demonstrably do, and under which conditions? |
| Authority | What may I do, what must I never do and which tools may I use? |
| Relationships | Who owns the outcome, who reviews my work and where does escalation go? |
| Operating state | Which version am I, what evidence supports my use, what is my lifecycle state and where does my trust apply? |
Authentication answers whether a worker is recognised. Access answers whether it can reach a system. Neither answers whether it should act on this task now.
Within NOID's proposed model, three ideas answer different questions:
| Concept | The question it answers |
|---|---|
| Confidence | How likely is successful and safe performance on this task under current conditions? |
| Trust | What reliance has this worker earned for this capability and context over time? |
| Assurance | Which controls and verified evidence make that confidence and trust defensible? |
A capable worker is not automatically eligible to act. NOID separates four questions that are often collapsed into one:
| Question | What must be established |
|---|---|
| Can it? | The worker and current version can perform this class of work |
| May it? | Authority covers this exact action, data, system and moment |
| Should it now? | Current context, evidence, controls, human fallback and recovery are adequate |
| Did it succeed? | The accountable route accepted the outcome and its consequences |
A score can inform a decision. It can never manufacture authority.
Delegation is the resulting decision: whether this worker may perform this work now, with this human-control pattern. A confidence estimate cannot override authority, safety or a non-delegable human decision.
NOID treats trust as:
- scoped to a capability, outcome and operating context;
- evidenced by observed work rather than declared confidence;
- revisable when the worker, model, tool, policy or environment changes;
- revocable when evidence weakens or risk rises; and
- non-transitive across workers, tools and tasks.
Trust can narrow after change, drift or weaker conditions; fall rapidly after a serious incident or evidence failure; be suspended while investigated; and expire when the supporting evidence becomes stale. A large number of easy successes should not average away a small number of severe failures.
More autonomy should require better evidence, not merely more time or a more capable model. A worker that has not earned reliance gets more supervision—not more freedom.
NOID does not treat the human as an approval button at the end of a machine process.
A useful human-control relationship gives the person context, time and evidence before the decision; the right to question, redirect, override or stop the work; and a record separating the worker's proposal from the human's decision.
The public escalation pattern is deliberately role-based:
Digital worker → Workforce lead → Human peer → Accountable owner
The exact people and systems will differ by organisation. The important thing is that escalation ends with an accountable human authority; it does not loop forever among agents.
A crew is an outcome-oriented team of people, digital workers and authoritative services. It shares a purpose, a bounded context and clear hand-offs.
The inheritance pattern is simple:
Organisation → Domain → Crew → Worker → Engagement
The crew layer gives participants a shared outcome, scopes context to the work, makes hand-offs visible and creates a home for team-level ownership, review and learning. It turns a collection of agents into a workforce people can reason about.
| Discipline | The question NOID forces into the open |
|---|---|
| Governance | Who owns the outcome and which decisions cannot be delegated? |
| Security | What is the least authority required, and how is it stopped or revoked? |
| Trust and assurance | What evidence justifies reliance on this worker for this work now? |
| Digital Worker Lifecycle — Agent HR | How is the worker introduced, evaluated, changed, suspended and retired? |
| Operations | Who sees exceptions, handles failure and keeps authoritative records reconciled? |
| Evidence | What record makes the outcome explainable, reviewable and recoverable? |
| Continuous improvement | How does feedback become an approved change rather than live drift? |
| Economics | What does the accepted outcome cost after supervision, controls and failure are included? |
One file does not solve these disciplines. Governance still defines decision rights; security enforces least privilege; connected systems implement stop paths; and accountable people operate and recover the service.
A secure digital workforce must be able to prevent, detect, contain, revoke, hand back, reconcile and recover—not merely authenticate an agent and restrict its tools. Consequential work needs a reachable human or manual route and a tested way to stop, roll back or restore service.
Observe → detect exception → contain → hand back → reconcile → recover → review
NOID describes the relationship and evidence. The connected runtime remains responsible for implementing and testing the controls.
The operating model, the digital worker and the capability or change each move through a separate lifecycle. Approval in one lane does not silently qualify the other two.
An approved framework does not certify a worker. A trusted worker does not automatically qualify a changed capability. A successful evaluation does not prove a live outcome.
NOID treats learning as a governed change process, not permission for a worker to rewrite itself in production.
Self-improving should never mean self-authorising.
Feedback can create a change proposal. It should not silently rewrite the live worker. Learning, evaluation, approval, release and proof of improvement are different states and should leave different evidence.
A useful local lesson becomes organisational knowledge only after evaluation, approval, controlled promotion and remeasurement.
Model choice follows the work: capability, data sensitivity, residency, context, latency, cost, availability and assurance. The work definition should remain stable enough to change model or runtime without rebuilding the accountability relationship from scratch.
Memory is not one ever-growing conversation log. NOID separates:
- current work and temporary context;
- events, decisions and outcome history; and
- approved knowledge that remains valid until reviewed or superseded.
Each memory needs scope, provenance, access, retention and a correction path.
NOID separates a stable work contract from the adapter that interprets or enforces it in a particular runtime.
Portability is a design objective: preserve intent, identity, authority, evidence and lifecycle when the platform changes—not a claim that every feature works identically everywhere.
A tool can return success while the wrong record changed, required evidence is missing, recovery remains open or the customer outcome is unresolved.
NOID therefore distinguishes action, technical result and closure. Work closes only when the accountable route can reconcile the evidence, determine the outcome and preserve any unresolved exception, recovery or consequence.
NOID's measurement position is to follow work from intent through acceptance and later consequences, rather than treating agent activity as value.
| Measure | Why it matters |
|---|---|
| Outcome acceptance | Shows whether the accountable route accepted the result |
| Quality and rework | Exposes plausible-looking output that creates more work |
| Evidence completeness | Shows whether the result can be challenged and reconstructed |
| Intervention and exceptions | Reveals where supervision and recovery capacity are consumed |
| Latency and capacity | Shows whether the route works at the required pace and volume |
| Risk and incidents | Captures consequences rather than only successful completions |
| Value and fully loaded cost | Tests whether the complete human-digital route is worthwhile |
The evidence receipt connects the definition, worker result, human decision and accepted outcome so that trust, economics and learning can examine the same record.
Digital performance should be reviewed for a specific worker, capability, version, scope, operating context and risk class—not as one universal agent rating. The performance record should include acceptance, quality, rework, exceptions, intervention, evidence, incidents, recovery, cost, drift and human impact.
For supervisory capacity, measure active decisions, exceptions and consequential scopes per supervisor—not simply agents per human. See Trust has an address for the deeper public view.
Token price is useful consumption data. NOID proposes a broader management lens for evaluating the route to an accepted outcome:
Fully loaded digital-work cost
= model + compute + tools + data
+ platform + orchestration + observability
+ design + evaluation + controlled change
+ identity + security + governance + assurance
+ human supervision + approval + exception handling
+ incident + recovery + reconciliation + rework
+ shared operations + continuous improvement
A multi-worker route must also include orchestration, duplicated context, handoff loss, delegation checks, correlated failure and the human capacity needed to supervise exceptions.
The proposed unit of comparison is:
Fully loaded cost per accepted outcome—considered with quality, risk, latency, capacity and value.
This is a design proposition, not a validated pricing standard. Tokens, licences, API calls and infrastructure are inputs; the organisation must still define acceptance, value and the controls required to rely on the result.
NOID stands on its own. A reader does not need a private repository or product implementation to understand or use its public contract.
| Surface | Role | Public boundary |
|---|---|---|
| VirtuallyNoIdea | Benjamin Johnson's workshop, operator and publishing identity | Accountable origin, not a certification body |
| Digital Workforce Management | The open management discipline for mixed human, digital-worker and service workforces | NOID offers one way to practise it; no claim of exclusive ownership |
| NOID | The open framework, public design language, small work contract and synthetic proof surface | This clean-room repository |
| Seven pillars | The proposed operating-model structure around governance, economics, lifecycle, operations, learning and assurance | Proposition-level concepts; private control mechanics remain out |
| DWOS | The platform-neutral system concept an organisation could operate around the workforce | A concept, not a product delivered by this repository |
| Primitives | A separate VNI product and implementation direction | Not required by NOID; no private catalogue, schema or implementation is copied here |
| Beyond Agents | The VNI thought-leadership stream developing the wider operating-model argument | A conceptual source, not implementation or production proof |
The relationship is conceptual. NOID remains useful without the other layers.
| Typical agent starting point | NOID starting point |
|---|---|
| Choose a model and give it a task | Define the accepted outcome and accountable owner |
| Express the agent in runtime-specific code | Express the work contract in readable, versioned artefacts |
| Treat tool access as permission | Separate capability, access and authority |
| Add human approval near the end | Design review, intervention and stop from the beginning |
| Measure responses and token spend | Measure accepted outcomes, evidence, risk and fully loaded cost |
| Improve the prompt in place | Evaluate, approve, promote and remeasure a controlled change |
| Bind identity to one provider | Keep identity and work intent separate from model and runtime |
NOID is not competing to be the fastest way to launch an agent.
It is trying to make the work clear enough that an organisation can decide whether the agent should be launched at all.
The public repository shown earlier is organised as four reader paths rather than one giant agent configuration:
Story → README and public concepts
Contract → specification and one machine-readable work schema
Proof → synthetic team, executable demonstration and evidence receipt
Trust → limits, governance, security, provenance and validation
The fictional refund team applies the public vocabulary while referencing a small shared layer:
teams/harbour-bicycle-refund/
├── README.md # how to inspect and run the team
├── TEAM.md # outcome, owner and participants
├── work.noid.json # authoritative v0.1 work definition
├── case.json # invented input
├── expected-output.json # expected evidence receipt
├── run_demo.py # transparent simulation
├── workers/
│ ├── refund-reviewer.md
│ └── evidence-checker.md
├── skills/evidence-challenge.md # team-local method
├── workflows/refund-review.md
└── governance/decision-rights.md
shared/
├── workers/README.md # reuse without inherited authority
├── skills/policy-comparison.md # referenced by the team
├── tools/fictional-record-reader.md
├── workflows/README.md
└── governance/README.md
Start with the repository map, inspect the framework object model, open the worker anatomy, then compare the blank templates with the completed synthetic team and its shared public components.
The cards are not prompts, live configuration or additional authority. For
NOID 0.1, work.noid.json remains the only machine-readable work contract.
NOID 0.1 contains one synthetic two-worker demo, one work
definition, one small schema and dependency-free validation.
python3 -B checks/validate.py
python3 -B teams/harbour-bicycle-refund/run_demo.py
python3 -B -m unittest checks/test_validate.pyPassing structural validation means the work definition has the declared shape. It does not mean the work is safe, approved, compliant, economical or implemented.
That distinction is a feature.
NOID publishes the questions, public vocabulary, contract and synthetic proof surface—not anyone's production machinery.
The public repository does not include:
- a runtime or orchestration engine;
- private prompts, memory, agent rosters or organisation context;
- scoring algorithms, trust thresholds or decision policies;
- customer examples, employer material or operating evidence;
- production security controls, credentials or deployment topology;
- model-provider claims or private routing rules;
- pricing, cost assumptions or an unvalidated agent-hour standard; or
- claims that a structurally valid file is safe to execute.
NOID 0.1 is an early, deliberately small framework—not a certification
scheme, security product, runtime or industry standard. Its structural
validator and fictional demo check the declared public shape; they do not
prove safe operation, compliance or economic value.
The exact release state is recorded in the repository's tags and releases.
Software, schemas and machine-readable team material use Apache-2.0.
Documentation, templates, diagrams and original artwork use CC BY 4.0. See the
exact scopes, terms and attribution in LICENSE.
If an AI system performs work in your organisation tomorrow, what will you wish you had made explicit today?
Start there.
Then define the outcome, the identity, the authority, the human-control relationship, the evidence, the economics and the learning path before the system acts.
NOID
Beyond agents. Governed digital work.
Benjamin Johnson · VirtuallyNoIdea · Sydney, Australia