← Decision records

ADR-011: One standard, two profiles - core and scale - declared in the manifest

Context

The standard must serve a one-person side project and a corporate-grade repo without becoming either a toy or a bureaucracy. Some patterns are universal (living specs, decision records, the agent entry point); others only pay off with more people (tracker bridges, release-notes curation, CI-enforced gates, UX research cadence). The owner's constraint (2026-07-22): keep it one repo - a fork or "light edition" must not appear - but a solo adopter must not be asked to carry enterprise ceremony, and the distinction must not rot into an unreadable pile of footnotes.

Options considered

• A - A separate light repo / branch / subproject. Clean first impression; but two artifacts drift apart immediately, every fix lands twice, and the transition light -> full becomes a migration. This is the exact split-maintenance failure the owner fears. Rejected.
• B - Two prose documents ("full" vs "light" checklists). Cheap; but prose drifts from the actual requirements, nothing enforces it, and every new feature must remember to update both narratives. Rejected as the primary mechanism (fine as a rendered view).
• C - A profile field on manifest entries, verified per profile (recommended). Every entry in standard.manifest.json (files / sections / guards / decisions) declares profile: "core" or "scale". A repo states its profile next to its version pin; self-verify --profile core|scale (solo/team accepted as aliases) counts drift against the right subset. One source of truth, mechanical, and upgrading profile is a flag flip plus the delta - the same muscle as update-to-version. Docs render the two views FROM the manifest, so prose cannot drift.

Decision

Option C. The dividing principle, so future entries classify themselves:

Core is whatever keeps knowledge alive; scale is whatever coordinates people.

• Core (every repo, even one person): AGENTS.md entry point, taxonomy, living capability specs, decision records + catalog, backlog, ideas space, version pin + manifest + self-verify, living-docs rule, supply-chain cooldown.
• Scale (teams / enterprise): tracker bridge + statuses mirrored out, curated release notes (two-changelog stays, curation is scale), CI-enforced gates (solo runs the same guards locally/pre-commit), personas as a hard gate with a full roster (solo: one persona minimum, the gate stays), UX research cadence + design-token handoff, C4 diagram discipline.

The exact per-entry assignment is executed as PROF-1 (manifest field + self-verify support + the adoption doc's profile picker); this record fixes the mechanism and the principle.

Note (2026-07-22): the human-facing vocabulary was unified to the manifest's words - --profile core|scale everywhere; solo/team stay accepted as deprecated aliases.

Consequences

• Positive: one repo, one source of truth; a solo project adopts in an afternoon without carrying ceremony; an enterprise gets the full posture; profile upgrade is a measured delta, not a re-adoption; the light/full views are rendered, never hand-maintained.
• Negative: every future manifest entry must declare a profile (a one-word cost); the standard's own docs must resist explaining everything twice - the profile column, not parallel chapters.

Confirmation

standard.manifest.json entries carry profile; self-verify --profile exists and CI uses it; docs/adoption.md tells an adopter how to pick; a solo repo passing --profile core shows drift 0 while visibly not carrying scale-only artifacts.

Revisit when

A third audience genuinely appears (e.g. regulated industries needing an audit profile), or profile flags start appearing on individual rules inside docs - a sign the two-profile granularity is too coarse.

Related

• ADR-005 (the manifest is the align-engine - this extends its schema), ADR-008/009/010 (zones, skill classes, lifecycle), PROF-1 in backlog.md.

Read this page's markdown, or its source on GitHub.