Lumen Architecture Commit Briefing

Source material: extracted Gemini notes from meeting-videos, covering sessions from June 30 to July 2, 2026. This is a first-pass working brief; the original recordings should be used only to verify ambiguous points or high-stakes commitments.

Executive Summary

The project is aligning on a target architecture for Lumen Vision / One Vision as the orchestration and work-management layer for network implementation, planning, migration, and related field workflows. The strategic direction is to reduce fragmented legacy workflows, retire older BPM / Site Tracker / Net Build style patterns where feasible, and establish common workflow, tasking, data provenance, and integration patterns.

The architecture is not a single-system replacement. It is a staged hybrid transformation. Salesforce remains the source of truth for product orders, Blue Planet is the consolidation target for inventory, the Data Hub provides stitched read views for consumers, Kafka / CFKA is the event backbone, SAP remains important for material/documentation/supply-chain linkage, ServiceNow is expanding for ticketing/GCR, and field systems such as Flight Deck / Salesforce SFS / Byfrost still matter depending on persona and workflow.

The architecture commitment target mentioned in session 5.2 is mid-July, with roughly three weeks of discovery and depth-of-effort sizing to validate feasibility and integration-team capacity.

Visual Evidence From Video

I extracted first-pass architecture screenshots from all recordings into visual-extracts. A generated index of the extracted frames is available here:

Visual frame index

Each session folder also includes a contact-sheet.jpg for fast visual review.

Session 1: Target Ecosystem And Planning Request

The two most useful first-video frames so far are:

Visible architecture facts from the target ecosystem diagram:

The major inflight programs impacting process are explicitly listed as:
VoltRon - Inventory Consolidation
LumenVision - Engineering Workspace (Planning)
ERP / S4 Hana - Phase 2
3GIS upgrade - Planning enhancements
(NSA) NEO / SOM 2.0 - Product Management
Workforce Management Migration (SFS)
OnDemand Services (MCGW)
Product Simplification
Mainframe exit / LCFI
Ecosystem exit / product simplification
LumenVision is drawn as an engineering/planning workspace that interacts with BPI / VoltRon and construction orchestration.
BPI / VoltRon contains at least three visible logical layers: Network Resource, Network Order (Infrastructure), and Micro Workflow.
Construction orchestration is shown as a horizontal process with Site Survey, Design, Fund It, Source & Buy It Labor & Hardware, and Install It.
SAP S/4Hana is shown as the management stack for Capital Management, Vendor Sourcing, Logistics, and Assets.

Visible architecture facts from the planning request diagram:

The planning request flow starts from Initial Request (Opportunity).
The request branches into Location/s and Preliminary Design.
Preliminary Design is defined as the plan: what the team is going to do and the work types involved.
Location/s feed Engineering Disciplines Designs.
Engineering disciplines include:
OSP: Metro and Long Haul
ISP: Wave, Ethernet, L3
Power: Battery, Generator, etc.
Utility
Real estate
HVAC
Engineering outputs feed Materials (BOM, Equipment), Cost Estimates (Material, Labor), and Project Intervals / Milestones.

Session 2: Network-Initiated Order Management And Workflow Journeys

Key frames:

Visible architecture facts:

Network-initiated order management starts from Opportunity Management for capacity, headroom, install, decom, groom, build, etc.
OffNet/Red flow references Triton, Puma, and Netbuild.
Order staging tools feed Netbuild and FOA.
Orchestration/task presentation includes Netbuild/BPM/FlightDeck and FOA/Engineering Order.
Ancillary systems include Itential, BPMOS, Swift, EON, SAO, ASRI, etc.
Data analytics includes INID, FAT, and NAT Tool, with KPIs, order status, project management, and predictive capabilities.
The visible execution stages are Opportunity Management, Design and Diversity, Vendor Ordering, Build and Test, GCR, Night of Cut, and Post Groom.
Workflow journey goals include retiring BPM-orchestrated workflows, enabling BPI and OM automation integrations, enabling green ecosystem migrations into BPI, and creating standard scheduling workflow.
Explicit decision points include:
Order initiation: Lumen Vision.
Order orchestration and task presentation platforms: LV + FD.
Workflow entity: LV / Itential / FD via published workflow L4 requirements.
Network-initiated reporting source of truth: assumed INID.
ASR automation / POM / GPOM integration remains unresolved.

Architecture commit implication: the team needs a clear boundary between Lumen Vision, Flight Deck, Itential, BPI, Netbuild, FOA, and analytics/reporting. “Order initiation in Lumen Vision” is visible as a decision point, but orchestration and task presentation are still multi-platform.

Session 2 deep-dive observations:

Current-state network initiated order management:
Planning/opportunity management sits above the execution stacks and covers capacity, headroom, install, decom, groom, build, etc.
OffNet/Red references Triton, Puma, and Netbuild.
Work moves through order staging tools into either Netbuild or FOA.
Netbuild side has primary BPM / FlightDeck task presentation.
FOA side has primary CORE FOA + Engineering Order task presentation.
Ancillary workflows still exist for Itential, BPMOS, Swift, EON, SAO, ASRI, etc.
Analytics is explicitly outside/below execution, covering INID, FAT, NAT Tool, KPIs, order status, project management, and predictive capabilities.
Workflow migration sequence:
MVP starts with Red Network Initiated install/disconnect for NWKs, IP-NWKs, and Metro.
Later waves include RNI NWKs/IP-NWKs/Metro with enhanced task routing/restart, RNI OnNet Grooms, RNI BPMQS Voice and Others, RNI OffNet Grooms, and finally Universal Grooms no longer using BPM/Savion for task orchestration.
Manual tasking, blocking, reporting, cancels, and ASR automation are called out as part of the migration surface.
Important decision points visible on the slide:
Order initiation should be Lumen Vision.
Order orchestration/task presentation is LV + FD, not LV alone.
Workflow entity is still unresolved across LV / Itential / FD and depends on published workflow L4 requirements.
Network-initiated reporting source of truth is assumed to be INID.
ASR automation / POM / GPOM integration is unresolved.
Future-state grooms workflow:
The process starts in planning with Identify Opportunity, Create Project, and imported site/equipment flags into inventory.
Opportunity management and site survey paths converge into review/determine network build, new path defined, and opportunity validated.
This supports the claim that planning cannot be skipped; it is structurally upstream of execution.
Inventory/data integrity workflow:
Equipment install and add equipment to inventory are explicit upstream activities.
Requests created for implementation lead to project release.
The workflow branches into a general execution path and a data-cleanse path.
This supports treating data cleansing as a required gate/milestone even if the cleansing team/tool remains outside Lumen Vision.
Target workflow/system sketch:
LumenVision starts with a planning request.
If funding is needed, SAP Capital is involved before execution.
During design, LumenVision requests design through BPI Network Order.
LumenVision workflow spans execution.
ByFrost is drawn as the single pane in execution, receiving active network context and connecting work context to downstream systems.
PTO/Netflex handles Wave/TDM active network work, and IBM handles Ethernet/IP active network work.
WFM Field Techs and GCR are separate endpoints connected from the LumenVision workflow.

Session 2 questions to take forward:

Is “order initiation in Lumen Vision” already agreed for all RNI workflows, or only for the MVP install/disconnect scope?
Where is the authoritative workflow entity: Lumen Vision, Itential, Flight Deck, or a delegated model by workflow type?
What is the exact future role of ByFrost: single-pane UI only, context aggregator, task distributor, or operational source for some execution data?
Does INID remain the reporting source of truth after workflow migration, or is that a temporary assumption?
What is the target interaction between Lumen Vision and BPI: create network order, update network order, subscribe to status, or all three?
How will data-cleanse completion be represented: task, milestone, external status, dependency gate, or workflow state?
What systems must still perform work directly even after the “no swivel chair” target is accepted?

Session 3: AI, Source Of Truth, And Adaptive Decision Orchestration

Key frames:

Visible architecture facts:

The AI story depends on OneVision becoming a trusted source of truth.
The data platform promise is verified state, lineage, history, rollback, replay, and auditability.
Governance is framed as observability, evals, and guardrails.
Agentic execution is positioned for dispatch, CapEx, inventory, and billing.
The Adaptive Decision Orchestrator is described as dynamic workflow control for telecom build and operations.
ADO capabilities include adapting workflows in flight, automating fallout handling, connecting decisions to execution, supporting complex process paths, and improving operational resilience.
Example use cases include dynamic punchlists, decommissioning readiness, temporary deployment management, POR creation workflows, and crew capacity planning.

Architecture commit implication: AI should not be committed as an isolated feature. It depends on workflow state, data lineage, auditability, rollback/replay, and permissioned execution. The architecture should separate “AI recommendation” from “authorized action.”

Session 3 deep-dive observations:

OneVision 2026 roadmap:
AI-leveraged products include Smart Dossier Handler, Auto-PMO & Task Aligner, Mobile FieldWork App, Adaptive Decision Orchestration, AI Trust Engine, and 360-degree Build Navigator.
AI-centric platform evolution includes Solution Config Agent Suite, Platform Modernization, Vera Chatbot, and Scaled Fast Data Utility.
V2 release bars appear concentrated into Q3/Q4 2026, while the current marker is Q2 2026.
Shared product principles:
The collaboration model explicitly joins solution delivery, platform features/products, roadmap influence, AI governance, tailored skill needs, and agile development/tracking.
Permitting with Adaptive Decision Orchestration is described as productized and integrated with LumenVision.
Architecture reviews and formal AI governance submission are explicit, not optional.
Mobile Field Work is a clean-sheet mobile-first user experience, driven by Lumen field video processing and analysis using AI.
Source-of-truth requirement for AI:
The slide states that AI is only as trustworthy as the data layer underneath it.
The “what buyers want” layer is agentic AI execution across dispatch, CapEx, inventory, and billing.
The safety layer is governance: observability, evals, and guardrails.
The offered foundation is trusted source of truth: verified state, lineage, history, rollback, replay, and auditability.
Without AI enablement and trustworthy data, the slide calls out truck rolls, schedule slips, stranded revenue, compliance risk, and operational friction.
Adaptive Decision Orchestrator:
ADO is defined as dynamic workflow control for telecom build and operations.
It adapts workflows in flight with safe workflow changes, versioning, restart, rollback, and migration across active projects.
It automates fallout handling using workflow logic and AI-assisted steps to identify exceptions, route issues, and recommend next actions.
It connects decisions to execution based on project class, task status, approvals, field updates, or operational conditions.
It supports branching, joins, SQL steps, AI steps, and workflow-driven controls across build and ops programs.
It is expected to improve operational resilience without breaking process governance.
ADO-assisted permitting:
The visual flow shows permit needs triggering package needs, research/jurisdiction/requirements intelligence, assembling/validating packages, and executing build/package intelligence.
This is a good example of “AI in workflow,” because the AI assists repeatable process steps rather than acting as an unbounded chatbot.
Scaled Fast Data Utility / Kafka:
Kafka is positioned to move large volumes of data fast at low latency.
It mediates listen/produce patterns with near-zero message/data loss, replayability, idempotency, traceability, and validation.
It maps Kafka events to platform objects such as lease, permit, and order.
It contributes to multi-layer observability across tools, dashboards, runbooks, and predictive protections.
It supports exception handling through dead-letter queues and automated ticketing/actions, initially with rules and later via AI agents.
Example use cases include faster system integrations, improved context for real-time decisions, next-best-action AI through CDC/event data, and operations/IT performance gains.

Session 3 questions to take forward:

Which AI roadmap items are part of the architecture commit, and which are explicitly experimental or post-commit roadmap?
What system owns the trusted source-of-truth foundation for AI: Lumen Vision, Data Hub, source systems, or a layered model?
What minimum lineage, rollback, replay, and auditability capabilities must exist before AI can trigger operational actions?
What is the human approval boundary for ADO: recommendations only, task creation, date changes, external system updates, or all of these with controls?
Are Kafka/CFKA event object mappings already defined for product order, service order, network order, task, permit, site, BOM, and inventory changes?
What is the dead-letter/error-handling operating model: who owns exceptions, how are they surfaced, and where are retries/replays controlled?

Session 4: Lumen Vision Platform Capability Evidence

Key frames:

Visible capability facts:

Lumen Vision already supports grid-style project/task views, status coloring, forecast/actual style tracking, resource assignment, task acceptance patterns, filtered work queues, widgets, dashboarding, template/version concepts, and ad hoc task management.
This is evidence of current platform affordances, not proof that all target integrations already exist.

Architecture commit implication: distinguish between platform-native capability, configured workflow, and external integration. The UI can present work richly, but the commit still needs to define source-of-truth, write-back, and event contracts.

Session 4 deep-dive observations:

The platform demo shows concrete Lumen Vision / OneVision operational affordances:
Workplan task lists with task name, order number, projected dates, actual dates, task status, and work group.
Task statuses such as In Progress and Not Ready.
Work groups such as Construction, Commissioning, PTA, Accounting, and Real Estate.
Project metadata including project type, project phase, ready-to-build indicator, need-by date, and service-to-need variance.
Project comments and comments history.
Missing/required document fields.
Project team role fields such as project manager, construction coordinator, construction manager, planning specialist, operations technician, permitting specialist, and general contractor.
Dynamic filtering appears to support “my work” style views across tasks, projects, dates, statuses, and assignments.
Dashboard capability is visible through an embedded dashboard browser and source dashboard copy/edit pattern.
The session supports the idea that Lumen Vision can act as a work surface and reporting surface, but the demo alone does not prove external write-back or authoritative ownership.

Session 4 architecture commit implications:

Treat “platform can display/manage task fields” separately from “platform owns task truth.”
Define which task/project fields are native to Lumen Vision and which are synchronized from source systems.
Define the write-back model for task status, date changes, documents, project team assignments, and comments.
If dashboards become operational decision tools, define refresh cadence, lineage, and source-of-truth rules.

Session 4 questions to take forward:

Which task/project fields in the demo are Lumen Vision-owned versus imported/synchronized?
Do comments and document attachments need to sync to external systems, or are they Lumen Vision-only?
Are work groups/person-role assignments governed by templates, source-system ownership, or manual override?
Can dashboard metrics be traced back to authoritative objects and events?

Session 5.2: Work Areas, Project Phasing, And Integration Roadmap

Key frames:

Visible architecture facts from Five Big Areas:

Custom Networks includes permitting AI pilot, partner/user task assignment in LV, safety checklists, site survey linked to BAU activity, materials management, integration data feeds, and California project Fed instance.
Business-As-Usual is framed as moving BAU to North Star Architecture with exits from Netbuild, Armor, WFMT, SiteTracker, and Flight Deck.
BAU includes Order Management Phase 1 & 2, Service Delivery Phase 1 & 2, Project Helix including Site Survey, hyperscaler migration into LV, Grooms into LV, and Planning into LV.
FT3 focuses on LumenVision adoption and alignment with NI exit of SiteTracker for mass-market-related work.
LTO PMO includes NAT data sharing and partner data sharing via integrations.
Integrations include Kafka 2.0, API and data-feed standardization, source-system retirement and cutover, NSA transition with S4HANA/BluePlanet/Salesforce, plus NEO and WFM.

Visible architecture facts from Project Phasing:

The phasing runs from Q1 2026 through Q3 2027.
Integration project rows include Order Mgmt Waves, Order Mgmt Dark Fiber, Project Helix (Site Tracker), Project Helix (Armor), Project Helix (Netbuild), GLM Integration, S4HANA Integration, Salesforce Integration, 3GIS Integration, BluePlanet Integration, and WFM Integration.
Each row is staged through intake, analysis, design, and execution.
Visible role groupings include NI/OPS, Planners/NI/OPS, RE/NI, SC/NI, GIS/NI, and Planners/NI.

Architecture commit implication: this is probably the most useful visual artifact for your Architecture Commit role. It shows that the architecture is not one release; it is a program roadmap with dependencies across OM, Project Helix, GLM, S4HANA, Salesforce, 3GIS, BluePlanet, and WFM.

Session 6: Delivery Governance

Key frames:

Architecture commit implication: session 6 is less diagram-heavy and more delivery governance. The architecture risks are backlog quality, integration expertise, testing environments, release cadence, user feedback loops, and scope control.

Session 6 deep-dive observations:

Session 6 is mostly discussion rather than readable architecture diagrams; the useful artifacts are governance and delivery risks.
The team wants agile delivery but not process for its own sake. The backlog must be cleaned up before optimizing sprint mechanics.
Environment maturity is a risk. The discussion calls out the need for stronger testing environments, UAT timing, rollback capability, and release planning as integrations accelerate.
Integration expertise is a named gap, especially around APIs, Kafka, change data capture, object state changes, and traceability.
The team wants roadmap and status language to be business-impact oriented rather than tool-name oriented.
Task terminology matters: a task should imply authority, definition of done, and transactional tracking.
Discovery should move faster through strong-opinion drafts, PRDs, demos, interviews, and an 80/20 decision model.
Scope control is a recurring concern: late additions after demos/releases need firmer cutoff rules.

Session 6 architecture commit implications:

The architecture commit needs a delivery-readiness section, not only a target-state diagram.
Required nonfunctional commitments should include environment model, release controls, rollback/replay, UAT gates, observability, and integration support capacity.
Backlog hygiene is an architecture risk if enablers like Kafka headers, source-of-truth decisions, and object models are hidden under feature stories.
Business-language naming should be used in the commit artifact so stakeholders can align without decoding internal tools.

Session 6 questions to take forward:

What environments are required for multi-system integration testing before production cutover?
What rollback/replay capabilities are required by workflow, eventing, and source-system updates?
Who owns integration design across APIs, Kafka, CDC, traceability headers, and object-state changes?
What architecture enablers must be tracked as first-class backlog items?
What is the decision rule for late stakeholder changes after PRD/demo alignment?

Session Summaries

1. Lumen - June 30, 2026

Primary theme: enterprise landscape, Northstar direction, and the need for standardization.

Inventory consolidation is moving roughly 20 inventory systems into Blue Planet, although not every service, workflow, or legacy artifact will move cleanly.
Salesforce is the source of truth for product orders. The Data Hub is for stitched downstream consumption, not write/update authority.
Consumers should use the Data Hub for views; systems that need real-time updates should call source APIs directly.
Product order decomposition follows the product-order to service-order concept, with service orchestration handling macro stages such as survey, design, construction, activation, and diagnostics.
Infrastructure work and customer-order work need common processes for construction, sourcing, installation, and materials.
“Planning request” was introduced as the pre-product-order mechanism for feasibility, materials, cost, intervals, site survey, and capital/funding needs.
Material Master standardization through SAP is important to avoid part-number mismatches when preliminary BOMs move into Lumen Vision.
Roadmap needs decomposition into large capabilities, not just features, with scope, time, and cost as the planning dimensions.

2. Alignment Lumen 2 - June 30, 2026

Primary theme: Lumen Vision as orchestration platform and legacy workflow retirement.

Lumen Vision is positioned as the primary orchestrator for network work and order initiation.
Legacy BPM workflows should be retired through phased migration: simpler network installs/disconnects first, then more complex grooms and off-net scenarios.
There are 14 requirements documents that must align with workforce management and field activity handling.
Data cleansing is a required prerequisite but should remain outside Lumen Vision; it must be represented as a mandatory workflow milestone.
“Simple groom” classification was eliminated; grooms should follow standard Lumen Vision / BPI workflow for consistency and visibility.
Byfrost was discussed as a single-pane / aggregator capability for network work, especially for presenting field teams with templates, notes, and order context.
Important functional needs: parent-child relationships, parallel tasking, task routing by skills/workload, rollback/replay, cancellation handling, centralized notes, analytics, and inventory integration.

3. Lumen Alignment 3 - July 1, 2026

Primary theme: AI roadmap, platform demo, workflow/task architecture, and integration philosophy.

Roadmap includes adaptive decision orchestration, smart dossier/document handling, AI trust engine, automatic PMO task alignment, and 360-degree build navigator.
Adaptive decision orchestration has five key requirements: adapt workflows in flight, track versioning, migrate projects across workflows, identify fallout, and recommend next-best actions.
The platform direction favors uniformity over heavy custom configuration to reduce operational and testing risk.
TMF/telco domain concepts should be built into tracker trees and workflow patterns to reduce user/system error.
Lumen Vision demo showed hierarchical project records, task dependencies, forecasting, block calculation, task filtering, field history, and editable grid workflows.
Current Lumen Vision integrations are limited in places, but the intended direction is event-based integration and bidirectional system communication.
Key principle: users should not have to swivel between tools. If work is triggered from Lumen Vision but performed in another system, the systems should exchange task/data context.
A major discovery item is mapping business personas, roles, and where work is actually performed.

4. Lumen Alignment 4 - July 1, 2026

Primary theme: platform capabilities, AI governance, widgets, sandboxing, and field/mobile capabilities.

Lumen Vision supports task status, work-group/resource assignment, filtered daily work views, project portals, task path visualizations, task-level chat, and aggregated project context.
AI-generated insights should be actionable and tied to project structures, not just reports.
Template versioning is needed so future task/template changes do not disrupt projects already in flight.
AI architecture uses RAG servers, rule mapping, agent guardrails, metadata/activity logs, and human-supervised workflows.
AI should be embedded into deterministic workflows carefully, especially for schedule planning, FQC review, document comparison, and workflow recommendations.
A sandbox environment with demo data and governance is needed so experiments cannot leak into production without authorization.
Field Vision and Mobile Fieldwork focus on AI-assisted site access interpretation, image/photo quality review, 360-degree or spatial verification, and mobile-first field assessment.

5. Lumen Alignment 5 - July 1, 2026

Primary theme: roadmap alignment, capability planning, and moving from vision to accountable delivery.

The group emphasized roadmap sequencing: what is already committed, what needs sign-off, and what is longer-term vision.
There is a strong need to define capabilities, enablers, and user-facing features separately so architecture and delivery can be planned cleanly.
Integration work must be tied to personas and process types, not just tool names.
The architecture should avoid tool-centric naming and use business-impact language.
Scope control, review quality, PRDs, demos, cutoff dates, and stakeholder alignment are recurring risks.

Key visual frames:

Session 5 deep-dive observations:

The transformation strategy is explicitly two-step:
2026: from dispersed text comments to a structured single source.
2027+: from a structured single source to an automated and agentic experience.
The 2026 step is still human executed. It focuses on:
Establishing business objects with standard nomenclature, operational definitions, and relationship dynamics.
Objects/relationships called out include BOM, work order, work plan, milestone, task, service delivery work plan versus network build work plan, and types of build plans.
Moving delivery planning and execution into structured single-source LumenVision.
Adding more granular planning/status tracking for sites/spans versus routes and date-management fields such as baseline plan, projected forecast, and complete actual.
Building a project-management aggregation layer on top of execution management.
The 2027+ step is human supervised. It focuses on:
Seamless information flows across North Star systems: Service Order Management, BluePlanet, Workforce Management, SAP S/4HANA, etc.
Integration with existing automation micro-apps such as Intelligent Interval Quoting and Order Health Engine.
AI-enabled planning, forecasting, and execution management.
Evolution into AI-enabled project management.
The high-level roadmap visually sequences:
Event-based integrations via Kafka.
Service Delivery Embedded Base.
Order Management via BlueSteel.
Service Delivery North Star / Waves.
Sites and Routes via GLM / 3GIS.
Network Build for Waves / Dark Fiber.
Procurement via SAP S/4HANA.
Network Design & Inventory via BluePlanet.
NEO / Salesforce revenue and profitability.
Salesforce Workforce Management.
The roadmap repeatedly uses the word “unlock,” which suggests these are dependency gates, not merely feature releases.

Session 5 architecture commit implications:

The immediate architecture commit should not overpromise agentic automation. The visual roadmap says the first milestone is structured source-of-truth data and object relationships.
The architecture needs a canonical object vocabulary before integration commitments can be trusted.
Date management is a cross-cutting architecture topic, not just a UI feature, because baseline, forecast, and actual dates appear in the transformation model.
Kafka/eventing is an early unlock for downstream roadmap items, so event contracts and traceability should be part of the commit.
BluePlanet, S4HANA, GLM/3GIS, Salesforce/NEO, WFM, and BlueSteel are all roadmap participants; the commit should name which are in Release 1 scope versus dependency-only.

Session 5 questions to take forward:

What is the authoritative object glossary for BOM, work order, work plan, milestone, task, service delivery work plan, network build work plan, and build plan type?
Which date fields are canonical, and which system owns each one?
Is the project-management aggregation layer part of LumenVision, an analytics/reporting layer, or both?
Are Kafka event contracts required before BlueSteel/SOM, GLM/3GIS, S4HANA, and BluePlanet roadmap items can proceed?
Which “unlock” items are funded/committed versus aspirational roadmap?

5.2. Lumen 5.2 - July 2, 2026

Primary theme: Site Tracker exit, Project Helix, SOM 2.0, Kafka dependency, and target architecture timing.

Project Helix is the Network Implementation exit / optimization effort from legacy platforms.
Net-new projects should move from Site Tracker into One Vision / Lumen Vision to reduce migration effort and improve adoption.
The migration strategy is hybrid: immediate lift-and-shift with small safe improvements, plus a longer-term transformed solution.
Site Tracker migration testing is expected in early October, with a go/no-go by mid-November.
SOM 2.0 is a priority dependency for Waves and Dark Fiber. It must capture order data in Lumen Vision for tracking, forecasting, and workflow interaction.
Kafka 2.0 headers are a mandatory dependency for SOM 2.0 traceability.
Forecasting UI is desired but likely complex; manual forecasting at service-order-item level may be acceptable until Project Helix matures.
Blue Planet integration is deferred to a later phase pending a high-level information model, personas, and data exchange definition.
Architecture commitment target: mid-July, after discovery and effort sizing.

Key visual frames:

Session 5.2 deep-dive observations:

The work is organized into five major buckets:
Custom Networks.
Business-As-Usual.
Fiber to the Tower (FT3).
LTO PMO.
Integrations.
BAU is explicitly framed as moving to North Star Architecture while exiting Netbuild, Armor, WFMT, SiteTracker, and Flight Deck.
BAU work includes Order Management phases, Service Delivery phases, Project Helix with site survey, hyperscaler migration into LV, Grooms into LV, and Planning into LV.
Integrations explicitly include Kafka 2.0, API/data-feed standardization, source-system retirement/cutover, NSA transition involving S4HANA/BluePlanet/Salesforce, plus NEO and WFM.
Project phasing is shown across Q1 2026 to Q3 2027, with work rows for:
Order Mgmt Waves.
Order Mgmt Dark Fiber.
Project Helix (Site Tracker).
Project Helix (Armor).
Project Helix (Netbuild).
GLM Integration.
S4HANA Integration.
Salesforce Integration.
3GIS Integration.
BluePlanet Integration.
WFM Integration.
The phasing model uses intake, analysis, design, and execution as repeated lifecycle states.
Visible role groups include NI/OPS, Planners/NI/OPS, RE/NI, SC/NI, GIS/NI, and Planners/NI.

Session 5.2 architecture commit implications:

“Architecture commit” should probably produce a program-level dependency map, not just a system diagram.
Project Helix must be split by legacy exit path: Site Tracker, Armor, and Netbuild have different timing and role impacts.
Integration planning should be tracked separately from feature planning because Kafka, API/data-feed standardization, and source-system cutover are shared enablers.
Release planning needs to distinguish Order Management Waves/Dark Fiber from Project Helix work; they overlap but should not be conflated.
The role columns imply that persona/workgroup mapping is part of architecture, not only change management.

Session 5.2 questions to take forward:

Which of the five big work areas are inside the mid-July architecture commit?
Which legacy exits are mandatory deadline-driven: SiteTracker, Armor, Netbuild, WFMT, Flight Deck?
Does Project Helix own only NI exit work, or also planning, grooms, hyperscaler, and site survey patterns?
What does “source-system retirement and cutover” require for each integration row?
Are intake/analysis/design/execution states managed in LumenVision, Jira, roadmap tooling, or all three?
Who owns cross-program dependency management when OM, Helix, GLM, S4HANA, Salesforce, 3GIS, BluePlanet, and WFM timelines collide?

6. Lumen Alignment Vid 6 - July 2, 2026

Primary theme: agile governance, backlog discipline, team structure, metrics, and discovery process.

The product backlog must be cleaned up before tuning scrum/sprint mechanics.
Scrum is preferred over pure Kanban to keep delivery focused on prioritized, high-impact increments.
The team needs better environment strategy, testing depth, UAT timing, rollback capability, and release planning.
Dedicated integration/data engineering expertise is needed, especially around APIs, Kafka, change data capture, state changes, and traceability.
Grooms and network implementation may share a backlog unless scope becomes too large.
Business naming should replace tool-based roadmap labels, e.g. “network opportunity planning” rather than internal system jargon.
A task should imply authority, a definition of done, and transactional tracking.
Discovery should use strong opinion drafts, PRDs, demos, 360 interviews, spot interviews, and an 80/20 decision model to avoid endless alignment loops.

Architecture Mental Model

Think of the target architecture in layers:

Sources of truth and authoritative systems

Salesforce: product order source of truth.
Blue Planet: target inventory consolidation platform.
SAP / S4 HANA: material master, BOM, documentation, supply-chain / ERP linkage.
ServiceNow: ticketing and likely future GCR movement.
Field systems: Flight Deck, Salesforce SFS, Byfrost, and other field-specific tools depending on persona.

Orchestration and work management

Lumen Vision / One Vision: target workflow, tasking, visibility, dependency management, project hierarchy, and potentially order/work orchestration layer.
BPI / Net Build / Site Tracker: existing systems that are being phased, bridged, migrated, or replaced depending on workflow.

Integration and event backbone

Kafka / CFKA: event-based integration, real-time topics, traceability headers, replayability, observability, change data capture, and data provenance.
APIs: direct updates to source systems where write authority is needed.
Data Hub: stitched read-side view for consumers.

Intelligence and automation

Adaptive decision orchestration, RAG servers, rule mapping, agent guardrails, AI trust engine, schedule planning, document handling, and field/mobile intelligence.
Human-in-the-loop remains a core governance principle before actualizing AI-driven decisions.

Main Architecture Commit Questions

What is the exact commit scope for mid-July: conceptual target architecture, sequence of capabilities, interface inventory, or implementation-ready design?
Which workflows are in scope for the first committed architecture: Site Tracker exit, SOM 2.0, Waves, Dark Fiber, Grooms, planning/network opportunity, permitting, or all of them?
For every major object, who owns write authority: product order, service order, network order, planning/network opportunity, project, task, BOM, site, permit, forecast date, actual date?
What is the canonical object model for many-to-many relationships: multiple sites per order, multiple orders per site, multiple budget items, multiple service orders, multiple network builds?
When should Lumen Vision orchestrate work directly versus only expose/route work handled by another system?
What is the required bidirectional contract between Lumen Vision and field systems such as Flight Deck, Salesforce SFS, and Byfrost?
What does “no swivel chair” mean for each persona: embedded UI, API-triggered action, synchronized task, or read-only visibility?
Which integrations are event/topic based through Kafka, which are synchronous APIs, and which are temporary flat-file/manual bridges?
What traceability headers and correlation IDs are mandatory across SOM 2.0, Kafka 2.0, Salesforce, Lumen Vision, Net Build/BPI, and Blue Planet?
What is the migration boundary for Site Tracker: data-only migration, UI parity, process redesign, or selective improvement?
What is the cutover policy for net-new projects, in-flight projects, and historical projects?
What data-cleansing gates must be represented in workflow before network work can start?
How will Material Master and BOM ownership work across SAP, Lumen Vision, sourcing/logistics, and vendors?
What are the minimum environment requirements before development accelerates: dev, integration test, UAT, pre-prod, prod, sandbox/demo data?
What AI features are architectural commitments versus roadmap experiments?

Suggestions

Create a one-page capability map split into: committed now, commit after discovery, deferred, and experimental.
Build a system-of-record matrix for every core object and date field before agreeing to integration design.
Write a persona-to-task map for planners, designers, CRT, field techs, PMO, construction, service delivery, data cleansing, and managers.
Define the first three integration patterns explicitly: event notification, command/action API, and read-side stitched query.
Treat Kafka traceability headers as a non-negotiable enabler for SOM 2.0 and downstream observability.
Keep Site Tracker exit on a pragmatic hybrid path: lift-and-shift enough to meet the timeline, but block unnecessary redesign from entering the critical migration path.
Separate technical enablers from user features in the backlog so architecture work is visible and not hidden under UI deliverables.
Adopt business-language roadmap names so stakeholders understand outcomes without knowing internal tools.
Put AI behind governed workflow steps first, with human approval before task creation, date changes, or external system actions.
Do not commit to Blue Planet integration details until the information model and personas/data-exchange flows are settled.

Immediate Next Steps For Architecture Commit

Confirm the exact mid-July architecture commit artifact and approval audience.
Produce the object ownership matrix.
Produce the workflow scope list for Release 1 versus later releases.
Produce the integration inventory with pattern, owner, dependency, and target date.
Validate Site Tracker cutover and testing timeline against October/mid-November constraints.
Confirm Kafka 2.0 header delivery and SOM 2.0 dependency dates.
Identify which open questions require video verification versus stakeholder follow-up.