Force/Enforce/Verify (F/E/V) — Standard Pattern for Cross-Cutting Concerns
Status: Accepted
Date: 2026-03-03
Context
ADR-0199 (“Close the Loop”) proved that system knowledge only became reliable when it was made involuntary end-to-end: injected at prompt construction time, enforced at runtime, and audited through telemetry. ADR-0195 (mandatory memory participation) used the same shape: extension-level forcing, hook-level enforcement, and OTEL verification.
Both decisions succeeded where prior opt-in guidance failed. In every opt-in version, agents or functions could skip the concern under pressure, and failures stayed silent until downstream damage appeared.
Decision
Force/Enforce/Verify (F/E/V) is now the mandatory architecture pattern for all cross-cutting concerns in joelclaw.
A concern is not complete until it has all three artifacts:
- Force artifact — a non-optional mechanism that applies the concern by default (extension injection, prompt builder prepend, compile-time default, or equivalent).
- Enforce artifact — a runtime check that proves the concern was actually applied in execution (middleware gates, step guards, query assertions, policy validators).
- Verify artifact — an observable probe with periodic audit coverage (OTEL events + watchdog/scheduled checks + alert conditions).
No new cross-cutting concern may ship as policy text alone.
Consequences
- Implementation cost per concern increases because every concern now requires three explicit layers.
- Silent failure risk drops to near zero because skipping any layer becomes detectable.
- Design reviews and ADRs must include explicit F/E/V mapping.
- Completion criteria for cross-cutting work now include proof artifacts, not just code paths.
Existing F/E/V Implementations
| Concern | Force | Enforce | Verify |
|---|---|---|---|
| system_knowledge (ADR-0199) | buildPrompt injection + extension seed | planner failed-target skip + all stages query | knowledge-watchdog 4h cron + OTEL events |
| memory participation (ADR-0195) | memory-enforcer extension | session_start hook | OTEL memory.recall / memory.observe events |
Candidates for F/E/V Treatment Next
-
OTEL telemetry coverage
- Force: default telemetry wrapper in shared function scaffolds.
- Enforce: middleware asserts start/complete/error emission per run.
- Verify: scheduled coverage audit flags functions with missing event triplets.
-
CLI routing discipline (CLI-first over raw HTTP)
- Force: shared adapters expose CLI contracts as the default interface.
- Enforce: lint/runtime guards detect direct HTTP calls where CLI contract exists.
- Verify: OTEL event includes
interface=clivsinterface=raw_http; watchdog alerts drift.
-
Deploy verification (post-push checks)
- Force: push workflow templates require verification step invocation.
- Enforce: CI/local guard fails if required verification command output is absent.
- Verify: OTEL deploy audit events confirm Ready/Error check executed for each qualifying push.
-
Retry policy invariants (
retries: 0never acceptable)- Force: shared Inngest function factory sets minimum retry policy.
- Enforce: registration-time assertion blocks zero-retry functions.
- Verify: scheduled scan + OTEL compliance report for retry configuration drift.
-
Hexagonal import boundaries (no cross-package relative imports)
- Force: package templates and codegen emit
@joelclaw/*imports only. - Enforce: lint/AST rules block forbidden cross-package relative paths.
- Verify: periodic repo audit emits OTEL boundary-compliance metrics.
- Force: package templates and codegen emit
Adoption Rule
For every new cross-cutting concern ADR going forward, authors must include a Force/Enforce/Verify section and name the concrete mechanism for each layer.