NativeWork is a proposed open specification for describing organisations in which work is executed by people, software, or autonomous agents interchangeably. It defines work — not applications — as the stable unit of architectural description, and provides a declarative syntax, WorkML, for expressing it in machine-readable form.
Operational tasks that previously required human execution can now be performed by autonomous agents. Execution capability is no longer a fixed property of an organisation; it is a variable that changes as models improve.
In prevailing frameworks, the description of what an organisation does is embedded in the systems that do it. Replacing an implementation therefore requires re-deriving the underlying intent, which is rarely recorded independently.
Architecture is predominantly maintained as diagrams and prose. Autonomous agents cannot consume it, validate against it, or act on it, which places the architectural record outside the systems it is meant to govern.
Applications are the primary architectural entities. Work is described implicitly, through the systems that perform it, and cannot be reasoned about independently.
Work is the invariant. Agents, software and people are execution bindings against a task definition, substitutable without altering the definition itself.
NativeWork treats work as the primary entity of architectural description, and decomposes an organisation into four decoupled perspectives: intent, work, execution and technology. Each is specified independently and versioned on its own cycle.
The consequence is deterministic substitution. Because a task definition carries no assumption about its executor, an execution binding may be reassigned — from person to agent, from agent to service — without amending the task, its intent, or its dependencies. Organisational knowledge persists across changes in implementation rather than being re-derived from it.
The specification defines four layers, each addressing a single question and versioned independently. A change confined to one layer does not propagate to the others.
Declares the outcomes an organisation is constituted to produce. Expressed as goals, constraints and policies, with no reference to tasks, executors or systems. Provides the traceability root: every task resolves upward to a stated intent.
The layer without precedent in existing frameworks. Defines tasks, their dependencies, preconditions and outputs, independent of any executor. Because it holds no implementation detail, it remains valid across successive changes in execution and constitutes the durable record of organisational knowledge.
Binds each task to an executor: a person, an autonomous agent, or a software service. Bindings are point-in-time assertions and are expected to change. Supersedes Application Architecture, which conflates the binding with the work itself.
Describes the substrate on which executors operate: compute, data platforms, interfaces, model endpoints and deployment environments. Referenced by execution bindings; never referenced by the work layer.
The separation is what makes incremental substitution tractable. A task definition that names no executor can be rebound without amendment; a definition that embeds its executor cannot.
Tasks, intents, dependencies, preconditions and outputs. Contains no reference to executors or systems, and is therefore unaffected by changes in either.
Bindings from tasks to executors — person, agent or service — together with the conditions under which each binding holds. Bindings are revised independently, one task at a time.
WorkML is a declarative language for expressing the four specification layers as plain text. Definitions are authored once and consumed by tooling: documentation, diagrams, dependency graphs and validation reports are derived artefacts rather than maintained ones.
Files are plain text, so they diff cleanly, review as code, and version alongside the systems they describe.
// Work layer definition task "customer-onboarding" { intent = "Acquire and activate new customers" owner = "growth-team" step "verify-identity" { executor = ai-agent depends_on = [] intent = "Confirm customer is who they claim" } step "create-account" { executor = ai-agent depends_on = ["verify-identity"] intent = "Provision customer account" } step "risk-review" { executor = person depends_on = ["create-account"] intent = "Human review for high-risk cases" condition = "risk-score > 0.7" } step "welcome-email" { executor = software depends_on = ["create-account"] intent = "Notify and onboard the customer" } }
One file, three layers: declared intent, task dependencies, and executor bindings. Substituting an agent for a person is a single-field change; the task definition and its dependency graph are untouched.
The example above shows the shape of the language, not its full surface. The formal grammar, JSON schema and reference validator remain unpublished while composition, versioning and error semantics are settled.
Release under CC BY 4.0 and Apache 2.0 once the syntax is stable enough that implementations written against it will not break.
The specification is designed to be applied to an organisation already in operation. It does not presuppose a rebuild, and adoption may be confined to a single domain before being extended.
Express tasks, intents and dependencies in WorkML without reference to current systems. Existing process documentation is the usual input.
Record how each task is performed today — team, application or service — as execution bindings. This yields a baseline and exposes tasks with no clear owner.
Reassign individual bindings to agents where capability and risk tolerance permit. Scope of change is one task; the work layer is unmodified.
Revisit bindings as agent capability changes. The work layer accumulates organisational knowledge; the execution layer absorbs the churn.
A specification that has not been applied to real organisations is untested. The current priority is adversarial review and independent implementation — particularly from practitioners positioned to identify where the model fails.
Enterprise, solution and business architects applying the layer model to live estates, and reporting where the separation between work and execution does not hold.
Organisations modelling a bounded domain in WorkML and contributing the resulting patterns, edge cases and structural gaps back to the specification.
Vendors building parsers, validators and editors against the grammar, and researchers examining the formal properties of the model and its limits.
Material is released in stages. What is withheld is withheld for a stated reason, not indefinitely.
The four-layer decomposition, the separation of work from execution, and the adoption sequence. Sufficient to evaluate the approach, criticise it, or reject it.
Circulated to reviewers and Founding Partners. Withheld from general release until the layer semantics have survived application to real estates — publishing an unstable specification invites implementations against a moving target.
The language exists and is in use internally; an illustrative excerpt appears above. The formal grammar, JSON schema and reference validator are withheld until composition, versioning and error semantics are settled. A syntax published before those are resolved would break every implementation written against it.
Parser, validator and editor support under Apache 2.0, alongside an interactive agent for working through the model. Scheduled after the grammar stabilises.
A specification is only as credible as its governance. The current position is stated plainly below, including what has not yet been decided.
NativeWork and WorkML originate from work at Centipod, which currently maintains the draft and acts as editor. Authorship is not anonymous and the specification is not presently the product of a multi-party consortium.
The objective is transfer to independent governance once the specification stabilises and multiple organisations have implemented it. Until then, editorial control rests with the maintainer, and this section will record any change.
On publication, the specification text will be released under CC BY 4.0 and the reference tooling under Apache License 2.0. Apache 2.0 carries an express patent grant. Implementing the specification will require no licence from the maintainer, and none will be withheld.
Contributing organisations may hold commercial interests in tooling or services built on the specification. Any such relationship material to the governance of the standard will be disclosed on this page.
A limited programme for organisations willing to apply the draft specification to a real domain and submit the results for incorporation. Participation is technical rather than financial.
Partners are expected to:
In return, partners receive:
The programme confers no exclusivity over the specification and no preferential licensing. It exists to test the model against real organisational complexity before the first stable version is fixed.