Concrete Systems
Concrete systems are what happens when a specialist harness composition meets a real task family. They are not abstract design patterns -- they are installable, reviewable, verifiable packages that compose skills, workflows, adapter bindings, eval packs, and a harness profile into a named automation surface.
How concrete systems work
Every concrete system follows the same structure:
- A task family (e.g.
docs,research,code-review,release-validation). - A harness profile that defines routing, tool projection, verification, and rollout policy for that family.
- A workflow that sequences steps -- search, analysis, synthesis, review, evidence capture.
- Skills that provide reusable instructions and contracts for each step.
- Adapter bindings that connect portable capability contracts to concrete execution (CLI, subprocess, API, frozen-tool).
- An eval pack that defines fixtures, graders, and no-regression checks.
- Verification and activation posture that gates live use behind evidence and review.
The result is a named, shareable, versioned package that turns "help me with documentation research" into a governed, verifiable workflow rather than a freeform chat prompt.
Current posture
Holon's concrete systems are currently defined at the spec level. The Specialist Harness Contract (repo-internal spec at specs/holon-specialist-harness-contract/spec.md) defines the packaging convention. The Plugin V2 Core Contract (specs/holon-plugin-v2-core/spec.md) defines the asset families that compositions draw from. Live marketplace distribution, activation, and UI-driven install are deferred.
The first concrete system prototype targets a low-risk local-draft docs-research composition. This validates the manifest, search, install, review, and verification model without opening unsafe execution surfaces (no 3D modeling, coding delegation, third-party UI, or live piloting).
Task families
Task families are stable labels drawn from the same vocabulary used by search-before-build and harness self-upgrade. Examples include:
| Task family | What it covers | Typical skills and assets |
|---|---|---|
docs | Documentation research, authoring, review, drift detection | source-trail, citation-check, synthesis, link-validation |
research | Background investigation, OSS analysis, comparison notes | web-search, paper-summarization, evidence-collection |
code-review | Structured code review against contracts and patterns | diff-analysis, spec-alignment, regression-check |
release-validation | Pre-release checks, changelog verification, build gates | version-check, changelog-alignment, artifact-inspection |
planning | Goal decomposition, roadmap drafting, prioritization | goal-extraction, dependency-analysis, estimation |
Each family is a search term, a profile scope, and a composition namespace. The same family labels are used in search-before-build queries to find existing specialist harnesses before building new ones.
Trust and activation
Concrete systems follow the same trust model as other v2-core packages:
trustChannellabels (core,official,verified-publisher,community,public,local-draft,private-org,personal-private) control install friction, activation friction, and update posture.activationPosture(catalog-only,draft-installable,review-gated) controls whether the composition can be activated for live use.- Eval packs and evidence refs gate activation for non-
local-draftpackages. - The default posture is
catalog-only-- discoverable and reviewable, but not activatable -- to prevent untrusted harnesses from reaching live execution.
Where to go next
- Plugin Marketplace Boundaries -- marketplace taxonomy, specialist harness packaging, and boundaries
- Plugin Packages -- V1 package surface and capability binding
- What Are Harnesses -- the harness concept that concrete systems compose
- Holon's Harness Model -- the harness architecture behind concrete systems