How Heroes Communicate

Heroes in the Unbound Force swarm communicate through artifacts – structured files that follow a standard envelope format. This is the practical implementation of Constitution Principle I: Autonomous Collaboration: heroes collaborate through well-defined artifacts rather than runtime coupling or synchronous interaction.

Every artifact is self-describing. A consumer hero can interpret any artifact without consulting the producing hero, because the envelope contains all the metadata needed: who produced it, when, what type it is, and what version of the schema it follows. This makes hero communication asynchronous, auditable, and resilient to individual hero unavailability.

Envelope Format

Every inter-hero artifact uses a standard envelope with 7 fields:

FieldDescription
heroName of the producing hero (e.g., gaze, the-divisor, muti-mind)
versionVersion string of the producing hero
timestampISO 8601 timestamp of when the artifact was produced
artifact_typeOne of the 7 defined types (see Artifact Types below)
schema_versionSemantic version of the artifact’s schema (e.g., 1.0.0)
contextContextual references: current branch, commit SHA, and backlog item reference
payloadThe artifact-specific data object – structure varies by type but conforms to a registered schema

The envelope format ensures that every artifact is machine-parseable (Constitution Principle III: Observable Quality) and includes provenance metadata for traceability.

Artifact Types

The swarm defines 7 artifact types. Each has a designated producer hero and one or more consumer heroes:

TypeProducerConsumersDescription
quality-reportGazeMx F, Muti-Mind, Cobalt-CrushTest results, contract coverage data, CRAP scores, and risk analysis from quality validation
review-verdictThe DivisorMx F, Cobalt-Crush, Muti-MindAPPROVE or REQUEST CHANGES verdict with per-persona findings from the review council
backlog-itemMuti-MindMx F, Cobalt-CrushFeature or bug descriptions with priority scores (5-dimension composite) and acceptance criteria
acceptance-decisionMuti-MindMx F, Cobalt-CrushACCEPT, REJECT, or CONDITIONAL decision with rationale after reviewing the completed increment
metrics-snapshotMx FMuti-MindVelocity, quality trends, review efficiency, and CI health metrics for the current period
coaching-recordMx FAll heroesLearning feedback, actionable recommendations, and convention pack update suggestions
workflow-recordSwarm OrchestrationMx F, Muti-MindComplete workflow trace with per-stage timings, artifacts produced, and iteration history

Each artifact type has a registered JSON schema that defines the structure of its payload field. Schemas are versioned independently (the schema_version envelope field), allowing artifact formats to evolve without breaking consumers.

Lifecycle Stage Mapping

Artifacts flow through the 6-stage hero lifecycle. Each stage produces specific artifact types:

StageHeroArtifacts Produced
DefineMuti-Mindbacklog-item
ImplementCobalt-CrushCode and tests (not envelope-formatted artifacts)
ValidateGazequality-report
ReviewThe Divisorreview-verdict
AcceptMuti-Mindacceptance-decision
ReflectMx F / Orchestrationmetrics-snapshot, coaching-record, workflow-record

The implement stage produces code rather than envelope-formatted artifacts. All other stages produce at least one artifact that feeds into subsequent stages or into Mx F’s cross-hero analysis.

After a complete lifecycle, the reflect stage produces three artifacts that capture what happened (workflow-record), how it went (metrics-snapshot), and what to improve (coaching-record). These feed back into the next cycle’s define stage through Muti-Mind’s data-driven prioritization.

Next Steps

  • Read the Constitution to understand the principles that govern artifact communication
  • See Common Workflows for the full 6-stage hero lifecycle
  • Explore the Team pages to see how each hero produces and consumes artifacts