Harness & progressive delivery
Harness is the flags / progressive delivery / experiments plane. It is not a second infrastructure control plane — it routes traffic and contract observation safely.
Standards-shaped cores
| Core | Role |
|---|---|
| OpenFeature | Sole public flag evaluation API for application code (HoboOpenFeatureProvider / HoboFeatureClient) |
| OpenDelivery (HoBo-shaped) | Progressive delivery / weight shifts |
| OpenExperiment (HoBo-shaped) | Bounded experiments with metrics hooks |
| OpenTelemetry hooks | Export observation without inventing a parallel telemetry product |
FeatureFlagStore + delivery + experiment engines are composed by Harness.
Capabilities
| Capability | Role |
|---|---|
| Feature flags | Ranked evaluation with audit facts |
| Experiments | Bounded exposure |
| Gateway weights | Shift traffic across revisions/camps |
| Sandbox lanes | Isolate experimental contract observations |
| Delivery composition | Safe rollout steps shared with Trails |
| Continuous delivery plane | Workload-attested apply of Gatekeeper-approved sets (cloud control plane CD) composes Harness |
Rules
- Baseline subscribers ignore sandbox-lane events by default.
- Flag changes are facts — replayable, not console memory.
- Progressive steps still pass Gatekeeper when they mutate infra.
- Trails compose Harness for cutover; pure flag flips need no Trail.
- Agents change flags only under RBAC + policy (often require-approval in prod).
- App code evaluates flags through OpenFeature — not ad-hoc env bools that bypass audit.
CLI
hobo feature … for flag/progressive ops. Observe via inspect projections and event replay.
Testing
- Dual fixtures for flag on/off paths.
- Bridge shadow mode to compare experimental vs baseline.
- Chaos: partial weight shifts must not break claimed session consistency.
Related
Progressive delivery guide · Trails · Bridge modes · Identity · Matching