A draft standard specification for distributed co-creation intelligence based on role-differentiated Wings, Kazene-style coordination, and trace-aware interoperability.
This repository defines the core model, coordination principles, interaction protocol, shared context, provenance hooks, and interoperability profiles for Multi-Wing systems.
Multi-Wing aims to provide a standardizable upper abstraction for distributed intelligence across structure, protocol, and execution layers.
Status: Draft v0.1
Type: Open specification draft
Scope: Conceptual standardization + interoperable reference model
Canonical specification: spec/multi-wing-standard-specification-v0.1.md
This repository is the canonical home of the Multi-Wing Standard Specification v0.1.
It is intended as an open, evolving specification for distributed intelligence systems composed of role-specialized agents ("Wings"), shared coordination logic, and trace-aware interaction.
Current AI systems often converge toward one of two extremes:
- monolithic centralization
- fragmented multi-agent experimentation without shared standards
Multi-Wing proposes a third path:
distributed intelligence with explicit role structure, coordination principles, provenance awareness, and interoperable execution
The goal is not merely to build another agent framework, but to define a portable architectural standard for systems where multiple specialized units collaborate, adapt, verify, and evolve together.
Multi-Wing standardizes the minimum interoperable model for:
- Wing types and role specialization
- Kazene-style coordination principles
- interaction flows between Wings
- shared context structures
- trace and provenance hooks
- interoperability profiles
- execution-layer compatibility for distributed inference and real-time deployment
This specification is designed to bridge three layers:
-
Structure Layer
Defines what kinds of Wings exist, how they relate, and how distributed intelligence is shaped. -
Protocol Layer
Defines how Wings communicate, coordinate, revise, and finalize outcomes. -
Execution Layer
Defines how Multi-Wing systems can be mapped onto real runtime environments, including distributed inference, routing, and edge deployment.
Multi-Wing is built around the following design principles:
- role differentiation over monolithic intelligence
- coordination over command
- traceability over opacity
- adaptation over rigidity
- distributed resilience over central fragility
- interoperability over ecosystem lock-in
At the conceptual level, Multi-Wing adopts a distributed intelligence view in which global intelligence emerges from local specialization, structured interaction, and dynamic balance.
A Wing is a functional intelligence unit with a defined role, capability boundary, and coordination interface.
A Role defines the operational function of a Wing, such as generation, verification, routing, memory, governance, or audit.
A Capability is a declared competence a Wing can perform under defined constraints.
A Task is a unit of coordinated work that may involve one or more Wings.
A Shared Context is the structured information space used for coordination, memory, references, and state continuity.
A Trace Reference is a provenance-aware reference object linking outputs to sources, contributions, or prior transformations.
Kazene refers to the coordination logic of dynamic balance, local interaction, emergence, and structured co-movement across Wings.
The Multi-Wing Standard Specification aims to:
- define a stable core abstraction for distributed intelligence
- provide an interoperable model for role-specialized agent systems
- support trace-aware collaboration and accountable co-creation
- enable compatibility across different runtimes, transports, and orchestration layers
- establish a foundation for future governance, verification, and value-allocation extensions
Multi-Wing v0.1 does not attempt to fully standardize:
- model weights or training procedures
- a universal semantic theory of agent cognition
- a fixed economic settlement protocol
- a single mandatory transport layer
- a complete formal verification system
- a single vendor-controlled implementation stack
This specification focuses on the minimum common structure required for interoperability and standardization.
multi-wing-standard/
├─ README.md
├─ LICENSE
├─ CHANGELOG.md
├─ CONTRIBUTING.md
├─ CITATION.cff
├─ spec/
│ └─ multi-wing-standard-specification-v0.1.md
├─ docs/
│ ├─ one-page-overview.md
│ ├─ architecture-overview.md
│ ├─ wing-type-system.md
│ ├─ kazene-coordination-principles.md
│ ├─ kazene-operational-semantics.md
│ ├─ wing-composition-rules.md
│ ├─ trace-lifecycle-model.md
│ ├─ interoperability-profiles.md
│ └─ relationship-to-mcp-a2a.md
├─ schemas/
│ ├─ wing-type.schema.json
│ ├─ message-envelope.schema.json
│ ├─ shared-context.schema.json
│ └─ trace-reference.schema.json
├─ examples/
│ ├─ wing-type.sample.json
│ ├─ message-envelope.sample.json
│ ├─ shared-context.sample.json
│ ├─ trace-reference.sample.json
│ └─ scenarios/
│ ├─ minimal-session.sample.json
│ ├─ review-loop.sample.json
│ └─ trace-integrated.sample.json
└─ .github/
├─ workflows/
│ └─ validate-specs.yml
└─ ISSUE_TEMPLATE/
├─ bug_report.md
├─ feature_request.md
└─ spec_change.md
-
spec/
Canonical specification text. -
docs/
Supporting architectural, operational, and interoperability documents. -
schemas/
JSON Schemas for core structural objects. -
examples/
Atomic schema-aligned sample objects for Wings, messages, shared context, and trace references. -
examples/scenarios/
Informative composite scenarios illustrating end-to-end coordination flows such as minimal sessions, review loops, and trace-integrated workflows.
If you are new to this repository, read in the following order:
-
docs/one-page-overview.md
A concise introduction to the overall idea and design intent. -
spec/multi-wing-standard-specification-v0.1.md
The canonical draft specification. -
docs/architecture-overview.md
A higher-level explanation of the three-layer model. -
docs/wing-type-system.md
Definitions of Wing categories and composition patterns. -
docs/kazene-coordination-principles.md
The coordination philosophy and normative interaction principles. -
docs/kazene-operational-semantics.md
The operational state model, rebalance conditions, and failure semantics of Kazene. -
docs/wing-composition-rules.md
Recommended, risky, and guarded combinations of Wing roles. -
docs/trace-lifecycle-model.md
Trace obligations across proposal, review, revision, finalization, and escalation. -
docs/interoperability-profiles.md
Profile-based compatibility guidance, including v0.2-oriented extensions. -
docs/relationship-to-mcp-a2a.md
Notes on interoperability and architectural alignment with adjacent protocol ecosystems. -
examples/
Atomic schema-aligned examples for individual structural elements. -
examples/scenarios/
Informative end-to-end coordination scenarios.
The first draft focuses on the following areas:
- Overview
- Terminology
- Core Model
- Wing Type System
- Coordination Principles
- Interaction Protocol
- Message Schema
- Shared Context
- Trace and Provenance
- Interoperability Profiles
- Security Considerations
- Conformance
This version is intentionally minimal enough to be implementable, while broad enough to support future extensions.
Multi-Wing assumes that intelligence becomes more robust when responsibilities are distributed explicitly.
Illustrative Wing categories include:
-
Generation Wings
Produce drafts, hypotheses, or candidate outputs. -
Verification Wings
Check consistency, evidence, safety, and quality. -
Routing / Coordination Wings
Assign tasks, manage workflow transitions, and maintain structured flow. -
Memory / Context Wings
Preserve continuity, retrieve references, and maintain shared context. -
Governance / Audit Wings
Track provenance, policy boundaries, and accountability hooks. -
Composite Wings
Combine multiple functions under controlled composition rules.
The formal type system is defined in docs/wing-type-system.md and the canonical specification.
Kazene is the coordination kernel of Multi-Wing.
It refers to a distributed mode of collaboration characterized by:
- local interaction
- self-organization
- emergence
- hierarchy across scales
- dynamic balance
- adaptation and reconfiguration
- containment of failure without total collapse
In practical terms, Kazene describes how Wings collaborate without requiring a single, absolute controller.
Multi-Wing systems are expected to support a structured interaction lifecycle such as:
- Discovery
- Capability Advertisement
- Proposal
- Assignment
- Execution
- Review
- Revision
- Finalization
- Escalation (when necessary)
The purpose of this lifecycle is to make multi-agent cooperation observable, testable, and portable across implementations.
Distributed intelligence requires shared structure, not just message passing.
Multi-Wing therefore includes a shared context model for:
- state continuity
- task references
- intermediate artifacts
- provenance metadata
- blackboard-style coordination
- knowledge graph references
- freshness and conflict rules
This allows Wings to cooperate through structured memory rather than stateless exchange alone.
A core differentiator of Multi-Wing is that coordination can be trace-aware.
Trace integration supports:
- provenance-aware outputs
- contribution references
- auditable chains of transformation
- signed event records
- future dispute-resolution hooks
- future value-allocation extensions
Multi-Wing v0.1 does not require a full economic protocol, but it provides structural hooks for one.
Multi-Wing is designed as an upper abstraction, not an isolated stack.
It is intended to interoperate with:
- model-tool context protocols
- agent-to-agent coordination standards
- legacy multi-agent system concepts
- transport-independent runtime environments
- distributed inference and split execution systems
In practice, this means Multi-Wing can be used as:
- a conceptual coordination model
- a portable protocol layer
- a normalization layer between different orchestration ecosystems
See docs/relationship-to-mcp-a2a.md for compatibility notes.
Multi-Wing v0.1 is intended to support conformance testing.
A conforming implementation should be able to demonstrate:
- support for the required core concepts
- a valid Wing role model
- a structured interaction lifecycle
- support for shared context objects
- trace-compatible message or output structures
- profile declaration and version identification
Future versions may define stricter conformance levels such as:
- Minimal Profile
- Cooperative Profile
- Auditable Profile
- Edge / Real-Time Profile
- Enterprise Profile
Multi-Wing is relevant to systems such as:
- distributed research assistants
- trace-aware co-creation systems
- multi-agent review workflows
- real-time edge intelligence clusters
- governance-aware AI collaboration environments
- distributed expert networks
- auditable knowledge work systems
The repository includes two kinds of examples:
Located in examples/, these provide schema-aligned sample objects for:
- Wing declarations
- message envelopes
- shared context objects
- trace references
These examples are intended for validation, implementation guidance, and object-level interoperability testing.
Located in examples/scenarios/, these provide informative end-to-end coordination flows such as:
-
minimal-session.sample.json
A minimal Multi-Wing flow with lightweight coordination and no independent review. -
review-loop.sample.json
A cooperative flow in which review changes the path of execution and triggers revision. -
trace-integrated.sample.json
An auditable flow with proposal, review, revision, finalization, and trace continuity across the lifecycle.
These scenarios are intended to show how the specification behaves as a coordination system rather than only as a set of isolated objects.
The schemas/ directory contains JSON Schema definitions for core structural elements.
Current schema targets include:
- Wing type definitions
- message envelopes
- shared context objects
- trace references
These schemas are intended to support:
- implementation consistency
- machine validation
- future profile testing
- sample object verification
You can validate sample files locally with standard JSON Schema tooling.
Example:
python -m pip install jsonschema
python - <<'PY'
import json
from jsonschema import validate
with open("schemas/message-envelope.schema.json", "r", encoding="utf-8") as f:
schema = json.load(f)
with open("examples/message-envelope.sample.json", "r", encoding="utf-8") as f:
sample = json.load(f)
validate(instance=sample, schema=schema)
print("Validation passed.")
PYRepository-level validation may also be automated through .github/workflows/validate-specs.yml.
- establish the core conceptual and structural model
- define the first interoperable draft
- publish schemas and examples
- provide compatibility notes with existing protocol ecosystems
- strengthen profile definitions
- expand trace and provenance objects
- clarify extension mechanisms
- refine conformance language
- add more executable examples
- formalize registry structures
- introduce broader governance patterns
- strengthen real-time / edge deployment guidance
- define richer testing and reference workflow suites
This repository is published on GitHub because standards require more than narrative explanation.
GitHub provides:
- version control
- transparent revision history
- issue-based discussion
- forkable reference implementations
- schema and example co-location
- public review and collaborative refinement
Articles, essays, and explanatory materials may exist elsewhere, but this repository is the canonical specification source.
Contributions are welcome.
This repository is a specification repository, so contributions should prioritize:
- clarity
- consistency
- interoperability
- testability
- extensibility
- accountability
Suggested contribution areas include:
- terminology refinement
- specification clarifications
- schema improvements
- example workflows
- interoperability mappings
- conformance language
- governance extensions
- security and failure-mode analysis
Please read CONTRIBUTING.md before opening a pull request.
For small editorial or schema-alignment fixes, a focused pull request is usually appropriate.
For substantial changes to terminology, lifecycle behavior, core Wing types, schema expectations, profile boundaries, or conformance language, open an issue first so the proposal can be discussed before implementation work begins.
When opening a pull request, please describe:
- what changed
- why it changed
- whether the change is normative or informative
- whether schemas or examples were updated
- whether conformance implications exist
The goal is not only to improve the text, but to keep the specification structurally coherent as it evolves.
You are encouraged to use GitHub Issues before opening larger changes, especially when the proposal affects the normative structure of the specification.
This repository provides three issue templates:
Use this for problems such as:
- specification inconsistencies
- schema validation failures
- mismatches between schemas and examples
- ambiguous required field behavior
- broken references or version mismatches
Use this for proposals such as:
- new examples
- new optional traits
- profile enhancements
- interoperability improvements
- documentation expansions
- non-breaking capability additions
Use this for substantive changes affecting the standard itself, such as:
- terminology revisions
- lifecycle changes
- required message field changes
- Wing type changes
- conformance rule changes
- profile boundary changes
Suggested templates are provided in .github/ISSUE_TEMPLATE/.
When possible, include:
- the affected file or section
- whether the issue is normative or informative
- whether schemas or examples are impacted
- whether backward compatibility may be affected
This helps keep discussion precise and makes it easier to review changes at the right architectural level.
This repository uses draft specification versioning.
- v0.x indicates early-stage, evolving drafts
- backward compatibility may change between minor drafts
- major stabilization is expected only after broader implementation and review
The canonical version identifier should always appear in:
- the specification file name
- schema metadata
- example metadata
- profile declarations where applicable
See LICENSE for licensing terms.
Unless otherwise stated, specification text, schemas, and examples are governed by the license declared in this repository.
If you reference this repository in research, articles, or derivative specifications, please use CITATION.cff.
Preferred citation metadata should include:
- specification title
- version
- repository URL
- publication or release date
- authors / maintainers
docs/one-page-overview.mddocs/architecture-overview.mddocs/wing-type-system.mddocs/kazene-coordination-principles.mddocs/kazene-operational-semantics.mddocs/wing-composition-rules.mddocs/trace-lifecycle-model.mddocs/interoperability-profiles.mddocs/relationship-to-mcp-a2a.md
Multi-Wing is not merely a framework for connecting agents.
It is an attempt to define a standardizable architecture for distributed intelligence in which specialization, coordination, traceability, and resilience can coexist.
In that sense, Multi-Wing is both a technical specification and a proposal for how co-creation systems may remain open, interoperable, and structurally accountable as they scale.
distributed intelligence, multi-agent systems, co-creation, interoperability, coordination, provenance, trace-aware systems, distributed AI, execution-layer compatibility, standard specification