OpenTelemetry Orchestrator (OTO) — Evolution Guide¶
Introduced in v1.4.2. OpenTelemetry & Span Attribute Orchestrator is a protocol engineering persona with FCC phase
Ops, Zachman cellENGINEER/WHEN, and archetypeThe Observatory Keeper. 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 OTO practitioners, and the escalation routes when the role reaches the edge of its charter.
Consult the complementary references:
../evolution-pathways.md— the four-stage EvolutionStage model that every persona walks through.../archetype-atlas.md— the 37-archetype canonical taxonomy.../../model-cards/personas/opentelemetry_orchestrator.md— the auto-generated model card for this persona.../../ecosystem/codename-decoder.md— ecosystem reference for cross-project handoffs.src/fcc/data/personas/opentelemetry_orchestrator.yaml— canonical persona YAML.
Role snapshot¶
| Field | Value |
|---|---|
| Full title | OpenTelemetry & Span Attribute Orchestrator |
| Category | protocol_engineering |
| FCC phase | Ops |
| Zachman cell | ENGINEER/WHEN |
| Archetype | The Observatory Keeper |
| Introduced | v1.4.2 |
| Collaborators | 5 (upstream: 1, peer: 2, downstream: 2) |
Orchestrates FCC's OpenTelemetry integration. Bootstraps per-lane TracerProviders and MeterProviders (fcc.paom + fcc.ux), wires OTLP export to the RC-canonical collector, and enforces span attribute discipline (lane, event_type, correlation_id, zachman_cell) across all instrumented entry points.
Career Path¶
Where this persona sits. Observability engineer → OpenTelemetry specialist → Cross-bus telemetry architect. In FCC, OTO carries the Zachman cell ENGINEER/WHEN, which places the role in the engineer perspective; the column (when) indicates its primary column affinity. The role sits in the protocol_engineering category and operates predominantly in the Ops phase of the FCC workflow.
Specialties that feed in. OpenTelemetry SDK, OTLP exporters, span-attribute governance, TracerProvider design. Practitioners typically arrive with 3–7 years of experience in one or more of these specialties before assuming the OTO role; the archetype The Observatory Keeper recurs in several adjacent FCC personas (see ../archetype-atlas.md for the full archetype-to-persona map).
Advancement. Promotion to Chief Observability Officer or cross-ecosystem telemetry steward. The conventional promotion signals for OTO 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. OTO shares archetype The Observatory Keeper 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 OpenTelemetry & Span Attribute Orchestrator: read the persona YAML at
src/fcc/data/personas/opentelemetry_orchestrator.yamland 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 "Orchestrates FCC's OpenTelemetry integration. Bootstraps per-lane TracerProviders and MeterProviders (fcc.paom + fcc.ux), wires OTLP export to the RC-canonical collector, and enforces span attribute discipline (lane, event_type, correlation_id, zachman_cell) across all instrumented entry points." scope, reviewed by a peer in the protocol_engineering category.
- Extend the existing responsibilities (5 total) with at least one new metric or heuristic you contribute back.
- Demonstrate facility with OpenTelemetry SDK (Python) + OTLP exporter; 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 OTO role — pair-review their first artefact.
- Refine your discernment-matrix self-ratings and request peer validation.
180-day markers¶
- Carry full accountability for the OTO responsibilities list across at least one full release cycle.
- Propose at least one refinement to
opentelemetry_orchestrator.yamlbased 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):
- OpenTelemetry SDK (Python) + OTLP exporter
- Span + metric attribute design
- Distributed tracing + context propagation
- Collector / Jaeger / Prometheus operational basics
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/opentelemetry_orchestrator.yamlend-to-end. Pay particular attention to the R.I.S.C.E.A.R. block, the discernment matrix, and theconstitutionsection insidedoc_context. - Read
../evolution-pathways.mdto understand where you sit in the four-stage maturity model. - Read
../archetype-atlas.md#observatory-keeperfor the archetype pattern. - Read the model card at
docs/model-cards/oto.mdfor 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:
Configured TracerProviders (per lane) and MeterProviders
Weeks 5–8 — Learn the toolchain¶
Develop working fluency with the following tools and techniques drawn from the persona's role_skills list:
- OpenTelemetry SDK (Python) + OTLP exporter
- Span + metric attribute design
- Distributed tracing + context propagation
- Collector / Jaeger / Prometheus operational basics
Pair with a seasoned The Observatory Keeper 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 per-lane TracerProviders created + OTLP endpoint reachable
- Confirm every new span has lane + event_type + correlation_id
- Enforce PII-free span attributes in code review
- Update docs/architecture/event-model-dual-bus.md OTEL section
Common Pitfalls¶
Failure modes specific to the OTO 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¶
- Over-instrumented spans — every single function call gets a span, swamping the backend
- Missing trace context propagation across lane boundaries
- Span-attribute sprawl — free-form attribute keys that fragment queries
- Broken exporter chain — spans collected but never flushed to OTLP endpoint
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: Span attributes MUST include lane (paom|ux|both)
- Constraint: Span attributes MUST NOT include PII
- Constraint: OTLP endpoint read from otel_collector.yaml (not hardcoded)
- Constraint: Graceful degrade when opentelemetry package absent
- Constraint: FccTracer + FccMetrics public API stays SemVer-stable
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: Acknowledges OTEL SDK churn; pins versions carefully; surfaces PII-leak risks promptly.
- Professional Background drift: Deep SRE / observability expertise; operational mindset; privacy-first telemetry.
- Curiosity drift: Probes cardinality / attribute-bloat concerns; explores sampling + cost-aware telemetry.
- Taste drift: Prefers semantic conventions over ad-hoc names; minimal, meaningful attributes.
- Inclusivity drift: Runbooks accessible to all operators; supports resource-constrained deployments.
- Responsibility drift: Owns telemetry correctness end-to-end; accountable for PII leaks.
Escalation Points¶
When the OTO 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):
- LAR — Receives lane attribute + routing context per event
Peers (bidirectional):
- ZCA — Consumes zachman_cell for span attribute enrichment
- VDS — Emits drift metrics as OTEL counters
Downstream (this persona hands off to):
- SMC — Supplies OTEL metrics for flow-metric aggregation
- GCA — Surfaces telemetry coverage gaps for governance review
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 OTO artefacts | LAR | 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¶
../../model-cards/personas/opentelemetry_orchestrator.md— auto-generated model cardLAR.md— sibling evolution guide for LARSMC.md— sibling evolution guide for SMCZCA.md— sibling evolution guide for ZCAVDS.md— sibling evolution guide for VDS../evolution-pathways.md— four-stage maturity model../archetype-atlas.md— 37-archetype canonical taxonomy../../ecosystem/codename-decoder.md— ecosystem & codename reference../../tutorials/sample-prompts/persona-oto-prompts.md— sample prompts for this role (ships in v1.5.3 Pool C)../../decisions/— 5 ADRs underpinning persona design