Files
bitgate/docs/adr/0001-four-decision-dimensions.md
T
thePR0M3TH3AN 2beb7a7bb5 feat: adapter contract, commerce proof-of-fit, and reusability docs
Proves the engine did not stay video-specific during extraction.

- application adapter contract in core (createApplicationAdapter,
  evaluateObject, collectTargets): an object names the targets that govern it
  and the strictest verdict reaching any of them wins, so denying a seller
  takes their whole catalogue down with no cascade logic in the application
- examples/commerce: a marketplace on the public API covering all ten
  proof-of-fit behaviors the plan requires, including that no core change was
  needed. One product, one snapshot, four surfaces, four different verdicts.
- README, integration guide, per-example README, CHANGELOG, four ADRs, and
  GPL-3.0-or-later LICENSE (the license was listed in Phase 1 but missing)
- checkpoints rewritten to reflect actual state and to say plainly which
  migration-plan phases belong to the consumer repos rather than here

Fixes a real gap found by the proof-of-fit: composeDecisions kept only the
first decision's evidence, so an object governed by several targets lost the
evidence that drove its verdict. Evidence now merges — counts summed,
contributor lists unioned, flags or-ed.

556 tests; lint, typecheck, and per-package type build clean.
2026-08-09 17:57:09 -04:00

1.4 KiB

ADR 0001 — Four independent decision dimensions

Status: accepted

Context

The reference application collapsed moderation into a small number of booleans (blurThumbnail, hideReason, blockAutoplay), computed in two places that overlapped. A commerce consumer needs a state those booleans cannot express: a product that is visible, inspectable, downranked, and unbuyable at once.

Decision

A decision carries four independent dimensions, each an ordered ladder:

  • ranking: normal → downrank (with accumulated weight)
  • visibility: allow → warn → restrict → hide → deny
  • interaction: allow → require-explicit-action → deny
  • transaction: allow → require-review → deny (present only when a profile can affect it)

Composition takes the ladder maximum per dimension.

Consequences

Composition is commutative and associative, so the order decisions arrive in cannot change the result — which is what lets an object be evaluated against several targets and merged without an ordering rule.

Consumers must map dimensions to their own UI rather than reading a boolean. That is more work at the call site and is the point: the mapping is application policy, and putting it in the engine is how the duplication started.

transaction is absent rather than allow when no profile gate can reach it, so a consumer can distinguish "explicitly permitted" from "not governed here".