Video Diagrams And Explanations
This page collects the key diagrams and visual architecture screens from Video 1 through Video 6. The synthesized architecture diagram is useful for presenting the target solution, but these screenshots are the evidence trail from the actual meetings.
Read this after the Customer POV, Q&A diagram, and Prep Pack. Use it when someone asks, “Where did that conclusion come from?”
Video 1 - Ecosystem, Planning, Source Of Truth
Target Ecosystem / Northstar Context
Shows the broader target ecosystem around product ordering, network implementation, and system exits. This is where the program starts to become more than a tool replacement: LumenVision has to sit inside a larger transformation landscape.
Planning Request Framework
Shows the planning request flow from opportunity or initial request into locations, preliminary design, engineering disciplines, BOM, cost estimates, intervals, and milestones. This is one of the clearest diagrams for why object definitions matter.
Source Of Truth And Connectivity
Highlights the source-of-truth concern: LumenVision can orchestrate work, but domain ownership must remain clear across inventory, order, materials, and reporting systems.
API Strategy / Data Integration
Frames integration as a core architecture topic, not a detail. APIs, events, and data contracts are necessary if LumenVision is expected to reduce manual coordination.
Construction / Product Infrastructure Flow
Shows infrastructure workflow dependencies across survey, design, funding, sourcing, labor/hardware, and installation. This supports the recommendation to define workflow boundaries by object and step.
Material Master Standardization
Shows why SAP/material master alignment is important. BOM and material objects should not be casually duplicated in LumenVision without ownership rules.
Video 2 - Network-Initiated Order Management And Workflow
Network-Initiated Order Management
Shows the target order-management flow across opportunity/order staging, Netbuild/FOA, orchestration/task presentation, analytics, and ancillary systems. This is central to Release 1 scoping.
Workflow Journeys / Transition Strategy
Shows workflow migration goals: retire BPM-orchestrated workflows where appropriate, enable BPI and OM integrations, and standardize scheduling/workflow behavior.
Red / Green Ecosystem Workflow
Shows the transition from legacy and target ecosystems. This supports a staged migration approach rather than a single big-bang replacement.
Business-Owned Applications Boundary
Shows that some applications remain business-owned or domain-owned. LumenVision should integrate with them instead of assuming universal ownership.
Program Dependency View
Shows cross-team dependency management. This is one reason the architecture commit needs a roadmap, not only a system diagram.
Inventory Integrity / Post-Migration Updates
Shows that data cleansing and inventory integrity are prerequisites. Workflow automation will fail if inventory state and update ownership are unclear.
Workflow System Design Sketch
Shows the target sketch where LumenVision connects with BPI, Flight Deck/WFM, ByFrost, GCR, SAP, and reporting. This is a strong basis for the architecture diagram.
Video 3 - OneVizion Roadmap, AI, ADO, Kafka
OneVizion 2026 Roadmap
Shows the roadmap themes: Smart Dossier Handler, Auto-PMO, Mobile FieldWork, Adaptive Decision Orchestration, AI trust, platform modernization, and fast data utility.
Shared Product Principles
Shows the principles behind the platform direction. This supports why the solution should be framed as workflow transformation, not just screen migration.
AI Source Of Truth
Shows that AI is only as trustworthy as the data layer below it. This supports the recommendation to keep AI human-supervised until lineage and governance are proven.
Adaptive Decision Orchestrator
Shows ADO as dynamic workflow control: branching, exception handling, decision steps, and adaptive execution. This is future-state capability, not an immediate autonomous commitment.
ADO-Assisted Permitting
Shows how AI/ADO could assist permitting lifecycle decisions. It is a good example of recommendation-first automation.
CFKA / Scaled Fast Data Utility
Shows Kafka/CFKA needs: low latency, replay, traceability, validation, DLQ, idempotency, and observability. This should be treated as architecture foundation.
Video 4 - Platform Capability Evidence
Task Status And Resource Assignment
Shows task grids, status, ownership, and assignment behavior inside the platform. This proves work-surface capability, but not source-system write ownership.
Dynamic Work Filtering
Shows how users can filter and manage dynamic work. This supports LumenVision as an operational work surface.
AI Dashboards / Generated Insights
Shows dashboard and AI insight concepts. The architecture still needs reconciliation rules so reporting does not conflict with source systems.
Template Versioning / Source View
Shows template and metadata behavior. This matters for repeatable workflows and controlled migration from legacy processes.
RAG / Rule Mapping Infrastructure
Shows AI/RAG/rule mapping direction. This reinforces that governance, permissions, and trusted data are prerequisites.
AI Agents In Workflows
Shows how agents may enter workflow execution. This belongs in later phases after guardrails and auditability are ready.
Video 5 - Roadmap, Domain Systems, Transformation
Two-Step Transformation
Shows the 2026 human-executed structured single-source step and 2027+ human-supervised automation step. This is the most important sequencing concept.
High-Level Roadmap
Shows roadmap dependencies across Network Build, SAP, BluePlanet, GLM/3GIS, Salesforce/NEO, WFM, and other programs.
Northstar / Integration Strategy
Shows how Northstar and integration strategy connect to the broader operating model. This supports staged release planning.
BluePlanet Migration And BOM
Shows why BluePlanet and BOM ownership should be handled carefully. Do not overcommit write integration before object boundaries are agreed.
Kafka And Micro Apps
Shows data integration through Kafka and micro-app patterns. This supports an event backbone rather than point-to-point-only integration.
Integration Strategy And Reporting
Shows integration/reporting concerns. Reporting must reconcile with operational source systems to avoid conflicting dashboards.
Video 5.2 - BAU, FT3, SiteTracker Exit, Integrations
Five Big Areas Of Work
Shows the major buckets: Custom Networks, BAU, FT3, LTO PMO, and integrations. This is useful for organizing roadmap ownership.
Project Helix / Optimization Terminology
Shows terminology and migration context around Project Helix. This supports a clear naming glossary for Architecture Commit.
Order Management And Dark Fiber Workflow
Shows project phasing and workflow sequencing for order management and dark fiber. This helps decide Release 1 versus later scope.
SOM 2.0 Integration
Shows SOM/BlueSteel dependency. This should feed the integration inventory and event-contract discussion.
Kafka 2.0 Dependency
Shows Kafka 2.0 dependency as a delivery enabler. Traceability headers and replay behavior are architecture commitments, not optional details.
SiteTracker UX Transformation Timeline
Shows SiteTracker exit timing and transformation risk. This supports separating deadline-safe migration from future-state redesign.
SAP Integration Requirements
Shows SAP integration requirements. Funding, materials, BOM, and procurement need clear source ownership.
BluePlanet Integration
Shows BluePlanet integration dependency. This should be treated as dependency or later-phase write integration until the object model is clear.
Video 6 - Delivery Governance And Readiness
Testing Environments
Shows environment and testing needs. Architecture Commit should include UAT, pre-prod, rollback, replay, and support readiness.
Backlog Management
Shows backlog and capacity concerns. This matters because architecture scope must be executable by available teams.
Integration Expertise
Shows need for API/Kafka/CDC/object-state expertise. Integration ownership should be explicit in the roadmap.
MVP Network Implementation
Shows MVP and network implementation strategy. This supports a bounded Release 1 architecture commitment.
Business Language / Naming
Shows the need for business-language naming and task terminology. A glossary is an architecture artifact, not just documentation cleanup.
Design And Integration Planning
Shows design and integration planning concerns. This reinforces the need for interface contracts and readiness gates.