Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ADR-033: Per-type policy: the profile-vs-log decay axis

Date: 2026-06-15 Status: Accepted (owner-delegated review, 2026-06-15) Author: Rômulo Febasi

Extends ADR-029 (trust/decay) and ADR-028 (open types). Reshapes the original SYN-248 “per-type governance policy” idea.

Context

SYN-248 was scoped as a full per-type governance policy (write_policy/pii/link_policy). For a single curator who already reviews every diff, a write-policy/PII matrix is gold-plating, the governance the gate provides is uniform, and a per-type write policy is a multi-actor affordance the single-user thesis doesn’t exercise (the v0.11 direction study, §3). The one genuinely useful axis the field surfaces is profile vs log: some facts are current-state (your name, your role, they don’t go stale), others are append-and-enrich logs (notes, decisions: they do). Today syn stale (ADR-029 decay) treats every AI fact the same, so a stable profile fact eventually gets flagged as “decayed”: noise.

Decision

Ship only the decay axis, as a [policy.<kind>] table in types.toml:

[policy.person]
decay = false        # profile: current-state, never flagged stale

[policy.note]
decay = true         # log (the default): participates in decay

A [policy.<kind>] block (not a field under [types]) so it covers the built-ins too, which are RESERVED in [types] and cannot be redefined. decay = false makes syn stale skip entities of that kind. Default (true, or no block) is unchanged behaviour. Advisory only: policy can never bypass or weaken the gate (BR-12.3 / ADR-022); it only changes what the advisory stale list reports. Deterministic; no engine, no DSL.

The broader write_policy/pii/link_policy surface is deferred (Open Decision #4 in the research): it is a multi-actor / Commercial concern, and adding it now would be a config surface a single curator rarely varies.

Consequences

  • Improves: profile facts stop appearing as false-positive “stale”; the stale list becomes higher-signal (the decay-as-daily-value-moment idea); a clean, tiny, deterministic policy surface that future per-type knobs can extend without a redesign.
  • Worsens: one more types.toml section to learn; a second config surface beyond [types] (justified by the built-in RESERVED constraint).
  • Open: write_policy/pii/link_policy (multi-actor governance); whether decay-exempt should also pin trust at its initial confidence in the ranking (SYN-250) rather than only exempting the stale list: deferred until there’s evidence it matters.

Alternatives considered

  • Full per-type write/PII/link policy. Over-built for single-user; a policy matrix nobody fills in. Defer to Commercial/team.
  • A mutability field on [types.<kind>]. Can’t express policy for the RESERVED built-ins (e.g. mark person as a profile). The [policy.<kind>] table is the surface that covers both.
  • Exempt by an entity-level frontmatter flag (x-no-decay: true). Per-entity is more granular but pushes the decision onto every write; the profile/log distinction is naturally a type property.
  • A policy engine (OPA/Cedar/Casbin). Deliberately over-powered for a single-user TOML; borrow nothing.

Research grounding

docs/researchs/2026-06-15-v0.11-issue-direction-study.md §3 (SYN-248); the profile-vs-log (“overwrite current state vs append-and-enrich”) distinction from the 2026-06-14 field study §2.3; ADR-029 decay curve.