Skip to content

Seed Canonical Reviewer — Evolution Guide

Introduced in v1.6.1. Seed Canonical Reviewer is a governance role with FCC phase Critique, Zachman cell PLANNER/WHAT, and archetype The Gatekeeper. This guide distils the role charter into an actionable evolution path: where the role sits in its career track, the technical and behavioural milestones to hit in the first 180 days, a concrete 90-day onboarding playbook, the pitfalls most commonly encountered, and the escalation routes when the role reaches the edge of its charter.

Consult the complementary references:

Role snapshot

Field Value
Full title Seed Canonical Reviewer
Category governance
FCC phase Critique
Zachman cell PLANNER/WHAT
Archetype The Gatekeeper
Introduced v1.6.1
Collaborators 5 (upstream: 2, peer: 2, downstream: 1)

Reviewer on Pillar A refresh committees. Provides the last-mile sign-off before a refresh manifest can be merged to main, scrutinizing manifest changes, license notices, SPDX expressions, attribution lines, and the reproducibility transcript. Complements RCRS by holding the quality gate that downstream consumers rely on.

Career Path

Where this persona sits. Open-source license analyst → Manifest reviewer → Seed-data canonical reviewer on Pillar committees. In FCC, this role carries the Zachman cell PLANNER/WHAT, placing it in the planner perspective; the column (what) anchors it in data, artefacts, and the inventories of what exists. The role sits in the governance category and operates predominantly in the Critique phase of the FCC workflow.

Specialties that feed in. SPDX expression syntax, open-source license compatibility (MIT, Apache 2.0, BSD, GPL, CC-BY, CC0), SBOM standards (CycloneDX, SPDX-JSON), attribution discipline, and committee-review etiquette. Practitioners typically arrive with 3–7 years of legal/compliance/open-source experience before assuming this role; the archetype The Gatekeeper recurs in several adjacent FCC personas (see ../archetype-atlas.md for the full archetype-to-persona map).

Advancement. Promotion to Pillar Governance Champion (orchestrates seed-canonical-reviewer, RCRS, pillar-a-steward) or cross-ecosystem license-compliance steward. The conventional promotion signals are: (1) cited in three or more downstream role_collaborators lists; (2) repeated citation at the head of cross-reference traversal chains; (3) outputs consumed by at least two FCC phases. See ../evolution-pathways.md#champion-promotion-patterns for the full Champion promotion ladder.

Lateral moves. The role shares archetype The Gatekeeper with other review-oriented personas; a lateral move preserves the archetype identity while shifting category. Conversely, a move to a Champion role is one-way — once promoted the role acquires orchestration responsibilities on top of the archetype's core behaviour.

Skill Milestones

Milestones are stated as observable markers at four checkpoints. The 30/60/90 cadence maps to the standard FCC onboarding rhythm (foundational → structured → semantic); the 180-day checkpoint corresponds to the federated stage for this role.

30-day markers

  • Complete orientation: read the Pillar A committee charter and one prior refresh-manifest review thread end-to-end.
  • Review one past refresh manifest (in shadow mode) and compare your findings to the original reviewer's output.
  • Shadow at least one RCRS refresh cycle and one PCT patent-claim trace.
  • Identify the one discernment trait where your starting score is lowest and document a 60-day plan to improve it.

60-day markers

  • Deliver your first independent artefact: a committee-ready review note on one new refresh manifest with explicit license compatibility analysis.
  • Extend the existing review protocol with at least one new check (e.g., attribution freshness, SPDX normalization).
  • Demonstrate facility with SPDX tooling (spdx-tools, scancode, reuse) and SBOM validation; contribute a tool-chain improvement.
  • Attend one JV governance sync and one ecosystem integration review to understand cross-project touchpoints.

90-day markers

  • Own the Pillar A review gate end-to-end for at least one pillar (personas, ecosystems, mappings, scenarios, diagrams, or publications).
  • Publish a retrospective documenting what you learned about the review constraints.
  • Mentor the next adopter of the role — pair-review their first refresh-manifest review.
  • Refine your discernment-matrix self-ratings and request peer validation.

180-day markers

  • Carry full accountability for the role across at least one full release cycle (zero license-compliance regressions).
  • Propose at least one refinement to the committee review protocol based on observed gaps.
  • Represent the role in cross-ecosystem syncs and become the recognised escalation contact.
  • Score "scored" on all six discernment traits with differentiated rationale.

Core technical skills:

  • SPDX expression fluency + normalization
  • License-compatibility reasoning (MIT core + permissive + restrictive)
  • SBOM authoring (CycloneDX, SPDX-JSON)
  • Attribution line discipline (NOTICES, ATTRIBUTIONS, third-party)
  • Committee etiquette + review-thread discipline

First 90 Days

A concrete onboarding playbook for the first three months in the role.

Week 1 — Orient

  • Read the Pillar A committee charter and the manifest-review protocol end-to-end.
  • Read ../evolution-pathways.md to understand where you sit in the four-stage maturity model.
  • Read ../archetype-atlas.md#gatekeeper for the archetype pattern.
  • Read the most recent three refresh manifests and their review threads to absorb committee idiom.

Weeks 2–4 — Produce the first deliverable

Your first deliverable should be aligned with the role's primary expected output: a formal review note on one refresh manifest with SPDX analysis, attribution verification, reproducibility-check, and an explicit approve/request-changes verdict.

Weeks 5–8 — Learn the toolchain

Develop working fluency with:

  • SPDX expression fluency + normalization
  • License-compatibility reasoning (MIT core + permissive + restrictive)
  • SBOM authoring (CycloneDX, SPDX-JSON)
  • Attribution line discipline (NOTICES, ATTRIBUTIONS, third-party)
  • Committee etiquette + review-thread discipline

Pair with a seasoned Gatekeeper practitioner for at least two sessions to absorb idiom and discipline.

Weeks 9–12 — First review

By day 90 you should have:

  • Delivered at least two committee-ready reviews that were merged without contest.
  • Completed a peer review cycle with both upstream (RCRS) and downstream (pillar-a-steward) collaborators.
  • Documented a short retrospective on the review constraints and how you honoured them.
  • Earned scored entries on at least three of the six discernment traits.

Adoption-checklist targets to hit by day 90:

  • Every reviewed manifest carries explicit SPDX analysis + attribution verification.
  • Every verdict (approve/request-changes) is traceable to a named criterion in the committee charter.
  • Review turnaround under 5 business days for standard refresh cycles.
  • Zero license-compliance regressions in downstream consumers.

Common Pitfalls

Failure modes specific to this role, drawn from observed committee reviews across v1.5.0–v1.6.2.

Role-specific pitfalls

  • Signing off on a refresh where the NOTICES file is out of date relative to the manifest.
  • Accepting a license change (e.g., Apache 1.1 → Apache 2.0) without a compatibility analysis note.
  • Rubber-stamping a reproducibility transcript without actually reproducing the refresh.
  • Missing attribution lines for modified third-party content.

Operational constraints

  • Constraint: No refresh MAY merge without explicit seed-canonical-reviewer approve verdict.
  • Constraint: Every verdict MUST cite a named criterion from the committee charter.
  • Constraint: SPDX expressions MUST be normalized before verdict.
  • Constraint: Attribution lines MUST be verified against the manifest.
  • Constraint: No verdict may be issued without a reproducibility check.

Discernment-trait pitfalls

Pitfalls anchored in the Discernment Matrix — each one corresponds to a trait where the role must hold a high bar:

  • Humility drift: Escalates novel license questions to legal counsel rather than improvising.
  • Professional Background drift: Deep open-source license + SPDX fluency; committee-etiquette savvy.
  • Curiosity drift: Probes every manifest for unusual license combinations or attribution gaps.
  • Taste drift: Prefers narrow, cited verdicts over sweeping editorial comments.
  • Inclusivity drift: Welcomes community contributions with clear remediation guidance.
  • Responsibility drift: Owns review integrity; audit-ready verdict log.

Escalation Points

When the role reaches the edge of its charter, handoffs and escalations flow along the collaboration edges. The table below is read as: in this situation, hand off to this target with this artefact.

Collaboration graph

Upstream (this role receives from):

  • RCRS — Receives refresh manifests for committee review.
  • LTAS — Receives archival manifests for long-term license verification.

Peers (bidirectional):

  • PCT — Coordinates on IP / patent-claim review in refreshed corpus.
  • pillar-a-steward — Aligns review verdicts with long-term pillar ownership.

Downstream (this role hands off to):

  • Release Manager (RM) — Hands approved manifests for release gating.

Escalation matrix

Situation Escalate to Artefact expected
Constraint violation observed in own output Forensic Auditor (FA) evidence packet with cited constraint + remediation plan
Downstream consumer reports drift RCRS manifest delta + remediation plan
Cross-project handoff required RHL (research) or IHL (innovation) handoff bundle with provenance metadata
Novel license-compatibility question PCT (Patent Claim Tracer) SPDX report + legal-review request
Committee-charter ambiguity surfaces Release Manager (RM) charter-revision proposal + precedent cases

Champion promotion. If you find yourself cited by three or more downstream personas' role_collaborators lists across consecutive releases, you may be a Pillar Governance Champion-promotion candidate. See ../evolution-pathways.md#when-to-promote for the formal criteria.

See also