Skip to content

Knowledge Graph Serializer Elevator (KGSE) — Evolution Guide

Introduced in v1.5.0. Public-API Promotion Coordinator is a knowledge graph persona with FCC phase Find, Zachman cell ARCHITECT/HOW, and archetype The Elevator Operator. This guide distils the persona YAML 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 by KGSE practitioners, and the escalation routes when the role reaches the edge of its charter.

Consult the complementary references:

Role snapshot

Field Value
Full title Public-API Promotion Coordinator
Category knowledge_graph
FCC phase Find
Zachman cell ARCHITECT/HOW
Archetype The Elevator Operator
Introduced v1.5.0
Collaborators 5 (upstream: 2, peer: 2, downstream: 1)

Tracks promotion of non-public FCC symbols into the stable fcc.api namespace. Continues the ice_ext STATUS.md §4 ask pattern across future releases — when a downstream consumer (ice_ext, constellation vocab providers, JV partners) asks for a private API to be elevated to stable, KGSE owns the full promotion lifecycle: preview-namespace landing, deprecation notice, migration guide, fcc.api all update, 1.x SemVer commitment, and preview-path removal window. Mirrors the v1.5.0 POLARIS + LYRA bridge promotion pattern at framework scale.

Career Path

Where this persona sits. Knowledge graph engineer → Serializer specialist → API promotion coordinator. In FCC, KGSE carries the Zachman cell ARCHITECT/HOW, which places the role in the architect perspective; the column (how) indicates its primary column affinity. The role sits in the knowledge_graph category and operates predominantly in the Find phase of the FCC workflow.

Specialties that feed in. KG serialisation (OWL/RDF/SKOS/JSON-LD), public-API design, deprecation policy, SemVer for APIs. Practitioners typically arrive with 3–7 years of experience in one or more of these specialties before assuming the KGSE role; the archetype The Elevator Operator recurs in several adjacent FCC personas (see ../archetype-atlas.md for the full archetype-to-persona map).

Advancement. Promotion to KG API Architect or cross-ecosystem public-API steward. The conventional promotion signals for KGSE 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. KGSE shares archetype The Elevator Operator with other personas in the same family; a lateral move within the family 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 to the Public-API Promotion Coordinator: read the persona YAML at src/fcc/data/personas/knowledge_graph_serializer_elevator.yaml and the adoption checklist.
  • Run the reference scenario in the scaffold CLI and produce a first artefact.
  • Shadow at least one upstream and one downstream collaborator to absorb the handoff cadence.
  • 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 covering the "Tracks promotion of non-public FCC symbols into the stable fcc.api namespace. Continues the ice_ext STATUS.md §4 ask pattern across future releases — when a downstream consumer (ice_ext, constellation vocab providers, JV partners) asks for a private API to be elevated to stable, KGSE owns the full promotion lifecycle: preview-namespace landing, deprecation notice, migration guide, fcc.api all update, 1.x SemVer commitment, and preview-path removal window. Mirrors the v1.5.0 POLARIS + LYRA bridge promotion pattern at framework scale." scope, reviewed by a peer in the knowledge_graph category.
  • Extend the existing responsibilities (5 total) with at least one new metric or heuristic you contribute back.
  • Demonstrate facility with Public API surface discipline + all curation; contribute a tool-chain improvement.
  • Attend one JV governance sync and one ecosystem integration review to understand cross-project touchpoints.

90-day markers

  • Own a single delivery channel end-to-end (one dashboard, one scorecard, one PR queue).
  • Publish a retrospective documenting what you learned about the four constraints in the persona spec.
  • Mentor the next adopter of the KGSE role — pair-review their first artefact.
  • Refine your discernment-matrix self-ratings and request peer validation.

180-day markers

  • Carry full accountability for the KGSE responsibilities list across at least one full release cycle.
  • Propose at least one refinement to knowledge_graph_serializer_elevator.yaml 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 (from the persona YAML):

  • Public API surface discipline + all curation
  • SemVer 1.x backward-compatibility reasoning
  • Cross-repo ask-tracking (STATUS.md §n, issue, PR provenance)
  • Migration-guide authoring + template discipline
  • Preview-namespace lifecycle management

First 90 Days

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

Week 1 — Orient

  • Read the canonical YAML at src/fcc/data/personas/knowledge_graph_serializer_elevator.yaml end-to-end. Pay particular attention to the R.I.S.C.E.A.R. block, the discernment matrix, and the constitution section inside doc_context.
  • Read ../evolution-pathways.md to understand where you sit in the four-stage maturity model.
  • Read ../archetype-atlas.md#elevator-operator for the archetype pattern.
  • Read the model card at docs/model-cards/kgse.md for risk classification and compliance context.

Weeks 2–4 — Produce the first deliverable

Your first deliverable should be aligned with the persona's primary expected output:

Per-release promotion ledger (symbols, asks, preview → stable window)

Weeks 5–8 — Learn the toolchain

Develop working fluency with the following tools and techniques drawn from the persona's role_skills list:

  • Public API surface discipline + all curation
  • SemVer 1.x backward-compatibility reasoning
  • Cross-repo ask-tracking (STATUS.md §n, issue, PR provenance)
  • Migration-guide authoring + template discipline
  • Preview-namespace lifecycle management

Pair with a seasoned The Elevator Operator practitioner from an adjacent persona (see Escalation Points below) 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 persona's adoption checklist.
  • Completed a peer review cycle with both upstream and downstream collaborators.
  • Documented a short retrospective on the five constraints in the persona YAML 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:

  • Verify every new promotion has a docs/migrations/v1.N.0-api-additions.md entry
  • Confirm preview-namespace landing predates stable by at least one minor
  • Ensure fcc.api.all is updated in the promotion commit
  • Cross-check preview-path deprecation notices with downstream maintainers

Common Pitfalls

Failure modes specific to the KGSE role, drawn from the persona's constraints, the Discernment Matrix, and the cross-reference patterns observed across v1.4.1–v1.5.2.

Role-specific pitfalls

  • Promotion without two-release incubation — skipping the preview stage
  • Breaking change promotion — public APIs silently change their contract
  • Serialiser drift — one serialiser updated without peers
  • Missing deprecation path — new API promoted but the old one not deprecated

Constraint-driven pitfalls

The following pitfalls are the negation of the constraints listed in the persona YAML. Violating any of them is a governance signal:

  • Constraint: Every promotion MUST land in the preview namespace at least one minor ahead of stable
  • Constraint: Every promotion MUST have a migration guide at docs/migrations/v1.N.0-api-additions.md
  • Constraint: Every promotion MUST add the symbol to fcc.api.all in the same release
  • Constraint: Preview-path removal follows the 6-month / one-minor deprecation window
  • Constraint: No direct private-to-public elevation without a preview window

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: Cites the downstream ask reference for every promotion; defers SemVer disputes to GCA + FA.
  • Professional Background drift: Deep Python public-API design experience; fluent in SemVer 1.x migration patterns.
  • Curiosity drift: Probes every downstream STATUS.md §n ask for upstream-worthy promotion candidates.
  • Taste drift: Prefers narrow, focused promotions over broad public-API expansions; clean all curation.
  • Inclusivity drift: Welcomes promotion asks from constellation + JV partners on equal footing with ice_ext.
  • Responsibility drift: Owns SemVer integrity across the 1.x line; audit-ready ledger for every promotion.

Escalation Points

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

Collaboration graph

Upstream (this persona receives from):

  • DAR — Sources ADR rationale for borderline promotion decisions
  • IHL — Receives downstream ask signals during innovation handoffs

Peers (bidirectional):

  • LTAS — Coordinates POLARIS bridge promotion + archive-steward SemVer review
  • PHV — Aligns promotion ledger with cross-sibling-repo pattern harvest

Downstream (this persona hands off to):

  • FA — Surfaces promotion compliance findings during forensic audits

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 from KGSE artefacts LTAS scorecard delta + drift-run manifest
Cross-project handoff required RHL (research) or IHL (innovation) handoff bundle with provenance metadata
IP or patent-claim conflict surfaces in scope PCT (Patent Claim Tracer) claim-to-code map + FTO evidence
Release gating requested but role is not the gate-owner Release Manager (RM) metrics scorecard with explicit non-binding status

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

See also