The accountability layer for dark fiber
Critical event records, incident lifecycle, and continuous monitoring in one carrier-grade system of record. Operators issue the proof. Enterprises see what they're paying for. One platform. One record.
Operator-issued. Customer-readable. Independently verifiable.
Multi-tenant from day one · Carrier-grade · No hardware lock-in
Customer disputes, audits, SLA credit reviews. Every escalation in dark fiber operations comes back to one question: what actually happened, and can you prove it? Without a system of record, the answer is reconstruction: engineering hours stitching together exports, optical traces, and timestamps after the fact. Theia replaces that with a signed artifact. Every optical event becomes an attributed, time-stamped record automatically, in a chain that holds up in front of customers, regulators, and finance.
Every optical event becomes a signed, attributed CER. No reconstruction. Ready for customers, auditors, and finance the moment it's issued.
Customer-facing views scoped per circuit. They get clarity on the fiber they pay for. You stay in control of what gets shared.
Multi-tenant dark fiber by design. Hundreds of circuits across thousands of spans, on one carrier-grade record.
You signed a contract for fiber you can't see. Theia gives you a continuous read on every circuit you lease, with full visibility into what's happening and where.
Continuous monitoring on the plant you pay for. No carrier handover, no filed ticket required to see what's actually happening.
The signed record your carrier references is the one you see. Diagnose together, not in parallel from different systems.
Built for finance, procurement, and risk. Every SLA conversation backed by data both sides already agree on.
One scenario. Two realities. A fiber break at 3 AM. Theia picks it up at the optical layer. Detection is the easy part. The harder part comes after. Without a governance layer, what follows is hours of reconstruction, fragmented evidence, and a downtime number that depends on whose log you trust. With Theia, the break becomes a signed, attributed, reconciled record automatically.
Most AI tools answer one question at a time. Theia Assist handles the whole investigation: pulling span history, correlating alarm sequences, checking SLA thresholds, and returning a finding with supporting evidence tied to the underlying data. You ask. It works.
Span serving Tenant B between Newark and Manhattan has deviated from baseline. Currently within SLA threshold. Pattern flagged for investigation before customer impact materializes.
Theia sits between your fiber infrastructure and your SLA obligations, converting every optical event into a verified, enforceable record. A single source of truth, automatically generated.
Twenty-six questions on platform mechanics, telemetry, the Critical Events Record, SLA math, security posture, Theia Assist, and deployment. Click any question to expand.
Theia Fiber is a SaaS monitoring and governance platform for dark fiber operators, carriers, and data center providers. The platform binds optical telemetry from Adtran inline OTDR hardware to the SLAs and contracts that govern fiber leases, producing an evidentiary record both the operator and the tenant customer can read from. Core capabilities include continuous span monitoring, SLA breach calculation against actual commercial terms, and the Critical Events Record (CER) for incident audit and dispute resolution.
Dark fiber operators, carriers, and data center providers on one side, and their tenant customers on the other. Both parties have logins and read the same telemetry record from the same platform.
The provider and the tenant both view the same record and information: the same span loss baseline, the same alarm timeline, the same CER. Neither side controls the record the other side reads. That separation is the trust mechanism.
An NMS detects faults. Theia attributes them. The output is contractual evidence: which span failed, which circuit was affected, which SLA was breached, what credit is owed. Detection is table stakes; attribution is the product. Theia coexists with your NMS rather than replacing it.
Dark fiber does not self-report. Adtran's inline OTDR injects a probe wavelength on the strand and measures the returned signal: insertion loss, reflectance, baseline drift, fault distance. The probe runs on a separate wavelength from any tenant traffic, so monitoring continues whether the strand is dark or actively carrying customer service. Theia consumes that telemetry continuously, binds it to circuits and contracts, and produces the audit record. The hardware produces the photons; Theia produces the accountability.
A signed, immutable record of a fiber event that materially affects a circuit. It contains the alarm chain, affected spans and circuits, baseline versus measured loss, the SLA terms in force at the time, the breach calculation, and the resulting credit if applicable.
Yes. Alarm states are written only by the Beacon. The UI cannot mutate alarm or CER records, and span geometry is locked after first save. Disputes happen through structured workflow, never by editing history.
Adtran inline OTDR today. The hardware injects the probe wavelength on the strand and produces the optical telemetry Theia consumes. Theia does not generate optical signal itself. Vendor expansion is on the roadmap; the platform is hardware-agnostic by design, so adding new vendors does not require rearchitecting the data model or the CER format.
Yes. Adtran inline OTDR is our launch integration and additional vendor integrations are planned as the ecosystem expands. The Beacon architecture and CER data model are vendor-agnostic by design, so new vendors plug into the existing pipeline without changes to circuit binding, SLA math, or the audit record. Customers running mixed plant should expect coverage to grow over time.
Yes. Traces are retained in their native SOR-compatible format and viewable in the Optical Analysis console. Baselines are captured at provisioning and used as the reference point for all deviation math.
Each circuit is bound to its commercial SLA terms: uptime targets, credit schedule, dedup window, grace policy, and chargeable states. When an alarm chain affects a circuit, accumulation math runs against those terms. Every step is auditable.
Yes. SLA terms are configured per circuit, not from a platform default. Existing master service agreements, custom credit schedules, and grace policies are modeled in the SLA Contracts console.
A CER is generated and made available to the provider. The provider can share it with the tenant at any time. Once shared, both parties view the same record and the same credit calculation. Whether the credit auto-applies or routes for review is a customer-side policy choice, not a platform default.
The CER is the evidence. Disputes are about interpretation, not data. Both sides see the same alarm timeline and the same SLA terms, which is what surfaces the disagreement clearly enough to resolve.
Two options. SaaS is cloud-hosted with strict tenant isolation. On-premise keeps the data inside the customer environment under the customer's data controls. No tenant ever queries another tenant's records in either model.
No. The Beacon initiates an outbound TLS session to Theia. There is no inbound listener on customer infrastructure and no inbound NAT rules to manage. The connection model is outbound-only, mutually authenticated, and follows standard zero-inbound deployment patterns.
Theia produces evidence aligned with BEAD reporting requirements. Span geometry, monitoring continuity, and outage records are exportable in the formats program officers expect to see.
Three things at launch. Answer plant queries in plain English. Alert proactively when measurements drift from baseline. Narrate alarms with diagnostic context. It is read-only and reasoning-only.
No, by design. Theia Assist will not initiate active operations on customer infrastructure, ever. This is a deliberate trust and liability decision, not a roadmap deferral.
It reads context relevant to the question being asked, scoped by the user's tenant and role. Conversations are not used for model training and customer data is not shared across tenants.
The Beacon is the on-site agent that talks to your Adtran inline OTDR. It reads telemetry, normalizes it, and forwards it to Theia over an outbound session it initiates from inside your network. It runs on a small VM or container in your environment and one Beacon typically covers a site or region.
Yes, for compliance, data sovereignty, or regulatory reasons. The same Theia stack runs in an isolated environment under the customer's control with the same data model, the same isolation guarantees, and the same CER format. The difference is operational: software ships as signed releases on a customer-controlled cadence rather than continuous SaaS rollout.
Span and port import from existing records typically completes within hours. Beacons download and deploy in under 30 minutes per site as a small VM or container. Baseline capture happens as the Adtran inline OTDR connection comes online.
No, Theia ingests data from the OTDR scanners, ALM probes, and chassis already in operation. The platform adds a governance and accountability layer above those tools. If a fiber operator already runs continuous monitoring on its plant, Theia integrates with that telemetry stream rather than duplicating it. There are no required hardware swaps or rip-and-replace projects.
For SaaS, features ship continuously with no customer-side install, no version freeze, and no upgrade window to coordinate. For on-premise, signed releases ship on a customer-controlled cadence so you decide when to upgrade.
Yes. Pilots scope to a defined plant footprint with a small number of tenant customers and run for an agreed period before commercial conversion.
Operators issue the proof. Enterprises see the truth. Both sides work from the same signed record. Join the operators and enterprises piloting Theia today.
No spam. Pilot access only. Unsubscribe anytime.