Skip to content

Pillar-A Steward — Evolution Guide

Introduced in v1.6.1. Pillar-A Steward is a data-engineering role with FCC phase Find, Zachman cell PLANNER/WHAT, and archetype The Custodian. 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 Pillar-A Steward
Category data_engineering
FCC phase Find
Zachman cell PLANNER/WHAT
Archetype The Custodian
Introduced v1.6.1
Collaborators 6 (upstream: 2, peer: 2, downstream: 2)

Long-term steward for Pillar A (seed data). Complementary to RCRS: where RCRS runs the quarterly refresh cycle, Pillar-A Steward owns the multi-release provenance chain, the cross-version manifest linkage, the historical license-compatibility log, and the deprecation/preservation decisions that span release bands.

Career Path

Where this persona sits. Data engineer → Corpus archivist → Long-term data steward. 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 across time. The role sits in the data_engineering category and operates predominantly in the Find phase of the FCC workflow, where it surfaces long-term signals for the refresh and archive cycles.

Specialties that feed in. Deep familiarity with FAIR data principles, provenance standards (W3C PROV-O, RO-Crate), long-term archival formats (BagIt, PREMIS), license-compatibility tracking across release bands, and deprecation reasoning. Practitioners typically arrive with 5+ years of data-stewardship experience before assuming this role; the archetype The Custodian recurs in several adjacent FCC personas (see ../archetype-atlas.md for the full archetype-to-persona map).

Advancement. Promotion to Corpus Governance Champion (orchestrates pillar-a-steward, RCRS, seed-canonical-reviewer, LTAS) or cross-ecosystem data-steward-of-record. 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 Custodian with LTAS; a lateral move preserves the archetype identity while shifting focus between long-term stewardship and long-term archival. 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 long-term provenance charter and the full manifest log back to v1.5.0 end-to-end.
  • Produce a first provenance-chain diagram for one pillar showing cross-release lineage.
  • Shadow at least one RCRS refresh cycle and one LTAS archive cycle.
  • 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 cross-release provenance report for one pillar with explicit lineage, license-evolution timeline, and deprecation signals.
  • Extend the provenance log with at least one new cross-release linkage check.
  • Demonstrate facility with PROV-O / RO-Crate / BagIt / PREMIS; 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 long-term provenance log for at least one pillar end-to-end.
  • Publish a retrospective documenting what you learned about the stewardship constraints.
  • Mentor the next adopter of the role — pair-review their first provenance artefact.
  • 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.
  • Propose at least one refinement to the provenance charter 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:

  • FAIR data principles (Findable, Accessible, Interoperable, Reusable)
  • W3C PROV-O / RO-Crate / BagIt / PREMIS literacy
  • License-evolution tracking across release bands
  • Deprecation + preservation reasoning (when to retire vs. archive)
  • Cross-release manifest linkage + lineage diagrams

First 90 Days

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

Week 1 — Orient

  • Read the Pillar A long-term provenance charter end-to-end.
  • Read ../evolution-pathways.md to understand where you sit in the four-stage maturity model.
  • Read ../archetype-atlas.md#custodian for the archetype pattern.
  • Read the full manifest log from v1.5.0 to the current release.

Weeks 2–4 — Produce the first deliverable

Your first deliverable should be aligned with the role's primary expected output: a cross-release provenance report for one pillar, with lineage diagrams, license-evolution timeline, and explicit deprecation signals.

Weeks 5–8 — Learn the toolchain

Develop working fluency with:

  • FAIR data principles (Findable, Accessible, Interoperable, Reusable)
  • W3C PROV-O / RO-Crate / BagIt / PREMIS literacy
  • License-evolution tracking across release bands
  • Deprecation + preservation reasoning (when to retire vs. archive)
  • Cross-release manifest linkage + lineage diagrams

Pair with a seasoned Custodian practitioner (LTAS) 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 artefacts that pass the role's adoption checklist.
  • Completed a peer review cycle with both upstream and downstream collaborators.
  • Documented a short retrospective on the stewardship 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 pillar has a complete cross-release provenance chain from v1.5.0 forward.
  • Every corpus entry has an explicit licence-evolution timeline.
  • Every deprecation candidate has a documented preservation decision.
  • Cross-release linkage is verified on every refresh cycle.

Common Pitfalls

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

Role-specific pitfalls

  • Letting the provenance log fall behind the refresh cycle (creates cross-release gaps).
  • Approving a deprecation without explicit preservation decision (loss of long-term record).
  • Rubber-stamping RCRS refreshes without checking cross-release linkage.
  • Missing a subtle license evolution (Apache 2.0 → Apache 2.0 with AGPL patch clause).

Operational constraints

  • Constraint: Every refresh cycle MUST update the cross-release provenance log within one release.
  • Constraint: Every corpus entry MUST carry a licence-evolution timeline.
  • Constraint: Every deprecation MUST carry an explicit preservation or retirement decision.
  • Constraint: Cross-release linkage MUST be verified on every refresh.
  • Constraint: Co-signature with RCRS required for all refresh manifests.

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 ambiguous lineage questions to the Pillar A committee.
  • Professional Background drift: Deep data-stewardship + provenance experience; fluent in PROV-O.
  • Curiosity drift: Probes every refresh for subtle license-evolution patterns.
  • Taste drift: Prefers narrow, precise provenance entries over sweeping summaries.
  • Inclusivity drift: Welcomes corpus contributions with clear long-term stewardship guidance.
  • Responsibility drift: Owns long-term provenance; audit-ready across multiple release bands.

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 cross-release provenance update.
  • chromium-sandbox-operator — Receives long-term cache manifests.

Peers (bidirectional):

  • LTAS — Coordinates long-term archive snapshots with provenance log.
  • seed-canonical-reviewer — Aligns stewardship decisions with committee verdicts.

Downstream (this role hands off to):

  • DAR — Hands provenance chains for decision-archaeology cross-reference.
  • PCT — Escalates IP / patent-claim conflicts surfaced in long-term provenance.

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 provenance delta + remediation plan
Cross-project handoff required RHL (research) or IHL (innovation) handoff bundle with provenance metadata
Deprecation decision contested seed-canonical-reviewer preservation vs. retirement proposal + precedent
Long-term license evolution risk PCT (Patent Claim Tracer) license-evolution timeline + risk analysis

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

See also