Feature Atlas

The Yuno Network operations platform is one place to watch a national fleet of public-Wi-Fi sites for the DICT, work the tickets that come out of it, plan the crews who drive to them, produce the paperwork the client expects, and show stakeholders what is happening without handing them a login.

One principle runs through all of it: a site visit is the last resort. Every automated recommendation walks the escalation ladder — check the provider cloud, call the site contact, and only then dispatch.

Everything that answers “which sites are up, which are down.” All of it reads the platform's own database, never live from a vendor, so a screen never hangs on a slow vendor API.

Fleet dashboard

• Live census — sites, access points and every network device, with online/offline counts and percentage. It sits above the date filter because it is current state the filter cannot reach.
• Uptime trend — one 30-day chart carrying three toggles: APs or sites, percentage or count, total or by project.
• Traffic, users and outage charts over the selected window, each with a by-project split.
• Backhaul rail — carriers ranked by site, since a site has exactly one uplink. The access-point total rides along as fan-out: how much of the fleet one carrier drop takes with it.
• Provider panel — the tile wall of carriers, site-weighted, with an “APs behind” view for blast radius.
• Device mix by product type, with the access-point subset called out separately.
• Behaviour summary — how many sites are always-on, scheduled, or irregular.
• Project rail for jumping straight into any project's NOC.
• Network Groups table, with a row indicator: amber for a site offline over 24 hours with no ticket, red for an open ticket left untouched over 48 hours.

Project NOC

Alongside the tabs: a data freshness indicator showing when each collector last ran, so a stale dashboard announces itself; an on-demand refetch; and AI Notes — local knowledge you write yourself (“Tingloy is an island municipality, brownouts are near-daily”) that is injected into every AI prompt for that project or area.

The rest of the monitoring surface

• Site detail — device inventory, uptime panel, realtime and historical user counts, location map, recent device alert logs, and the site's behaviour profile.
• Device detail — device info, uptime history, data-usage charts and unique-user counts for a single access point or router.
• Offline Monitoring — everything currently down across the fleet, sortable and filterable. The screen you leave open on the wall.
• Fleet map — every site with marker clustering, status colouring and click-through info windows.
• Hourly availability — a finer-grained uptime series than the daily rollup, for the days that need it.

NOC Daily briefing

A once-per-day operations report per project, generated the first time anyone opens the NOC that day and then frozen — so today's briefing is a record rather than a moving target, and past days stay scrollable as history. It carries the outage snapshot (area-wide clusters against isolated faults), online percentage versus yesterday, traffic and active users with deltas, what recovered overnight, what newly went down, and a plain-language narrative on top of the numbers.

Outage triage by geographic clustering

Sites within 10 km that are down together are grouped. Three or more in one cluster is treated as an area-wide event — power, weather or backhaul — and dispatch is held. A single site down while its neighbours are up is an isolated fault and a dispatch candidate. The clustering is deterministic and works with no AI available; the model only adds the briefing on top.

Site behaviour analysis

Many DICT sites sit in schools that cut the breaker after hours. The access point drops at around 6pm, returns at around 5am, and stays off all weekend — the site looks broken and is not. The platform learns each site's rhythm from reconnection events and classifies it scheduled, always-on or irregular, then uses that to tell a real outage from expected downtime. Sites carry a schedule tag — 24/7, SCHEDULED or STANDARD — that can be detected automatically or set by hand, with the manual override recorded.

Project settings

The contract desk: what this engagement is and whether it is still running. Contractual name plus the nickname the team says out loud and any aliases the contract answers to; lifecycle status (active, onboarding, on hold, suspended, closed) with a plain-language hint for each; the region; the contract window and a renewal countdown driven only by the end date, so a missing date reads as “not recorded” rather than “due”; where the renewal conversation stands; and the roster of operators, coordinators and installers. Everyone with project access can read it; only admins can save.

Shift handover

An end-of-shift record per project per day: what stays down overnight, whose 24-hour clock expires tomorrow, open tickets and the first action for the incoming shift — with an explicit “nothing outstanding” state and an acknowledgement by whoever picks it up.

Vendor API error log

Every failed vendor call is captured with type, status code, endpoint, entity and message — aggregated by fingerprint with first-seen, last-seen and occurrence count, and resolvable. Collector problems surface as data rather than as a mysteriously stale dashboard.

A full ticketing system built around how a NOC actually runs — per project, plus a network-wide dashboard for admins and a sanitised public board for stakeholders.

The board

• Kanban and list views, toggleable, with the choice remembered per user.
• Six lifecycle stages — NEW → COORDINATOR → IT → INSTALLER → REVIEW → DONE — where REVIEW is real QA: confirmed cause code, resolution note, site verified back online.
• Filter bar across project, status, severity, cause code, assignee and schedule tag.
• Ticket drawer with full detail, timeline, comments, attachments, equipment and parts used.
• Metrics strip — open counts, ageing, SLA posture.

The ticket model

Rich enough to answer a client's questions without a side spreadsheet: source (NMS alert, SMS, call, email, DICT, coordinator), reporter details, category and sub-category, severity tiers, P1–P4 priority, impact scope, uplink type and ISP, last-seen-online timestamp, DICT reference number, resolution type and summary, root-cause category, preventive action, closure code and duplicate linking.

Cause codes

Sixteen standard codes covering the real reasons Philippine public-Wi-Fi sites go down. UNK exists but can never be a closing code.

SLA tracking

Acknowledgement, first-response, resolution and dispatch clocks, each with its own due timestamp and breach record. Tickets carry ON_TRACK, AT_RISK or BREACHED, and a breach-prediction view flags tickets heading for a breach before they get there, weighted by severity and current posture.

Automated ticket generation

One click turns today's NOC Daily into tickets, following the playbook rather than blindly raising one per down site.

1. Cross-check the provider cloud. Down on both is a real outage. Down on the NMS only is logged as an NMS-DISC discrepancy, with no ticket.
2. Check the schedule tag. A 24/7 site tickets immediately. A scheduled site inside its window does not ticket. Outside its window it is treated as standard.
3. Apply the standard hold. Standard sites get 24 hours; still down at 24 hours, they ticket.

Area-wide clusters skip the flow and ticket immediately — a cluster is already signal enough. Sites with an open ticket are skipped.

Assignment & accountability

• Installer site ownership — one installer covers each site by default, driving their “tickets at my sites” board.
• Emergency cover — dispatch an installer who does not own the site and they see it under “assigned to me”, without changing who owns the site.
• Contact-attempt logging — who was called, when, and what they said.
• Verification records — the QA evidence that closes a REVIEW.
• Contributor tracking and a full per-ticket activity log.
• Comments, attachments, equipment, affected services and parts used as first-class records.

Step two of the escalation ladder is “call the site”. That number has to be one click away, and it has to be visible who is missing one.

• Contacts directory — every site contact, searchable, with add and edit.
• Coverage table — which sites have a contact on file and, more usefully, which do not.
• Site record — site code, DICT site number, address, barangay, locality, province, region, coordinates, site type, last-mile technology, activation date and validity period.
• Assignment — the covering installer, and the schedule tag with its manual-override flag.

Zones are scoped to a region rather than a project, because crews cover ground and the ground is shared: thirty municipalities carry sites from two different contracts. Per-project zoning would have drawn the same town twice and put one crew in two places.

The hierarchy is region, then province, then municipality. Zones live in a region and hold municipalities; province is the level between, used for grouping. A zone is a handful of municipalities or a whole province, so there is no province tier to assign to — crews attach to zones.

Maps

• Philippine region map — the page opens on all 17 regions with the covered ones lit, because picking where you work is a geographic act.
• Region drill map down to province and municipality.
• Zone coverage map with a per-zone colour, fullscreen and zoom controls, and pin-spreading where sites sit on top of each other.

Crews

• A team is a crew, not a person: regional, named, with members drawn from the user directory.
• A crew has a base — a short label plus a real searchable address, geocoded on save into coordinates. The first and last drive of every planned day hangs off this.
• A zone has at most one primary crew, whose coverage every site underneath inherits, plus any number of support crews for surges and leave, which inherit nothing.

Pick a zone and get a costed multi-day itinerary: ordered stops, real drive times, overnight decisions and a per-day brief drawn on a map. Plans are filed under the zone, so a plan survives a crew reassignment and one crew's several zones do not overwrite each other.

• Monthly coverage — every site in the crew's primary zones, whatever its status.
• Priority — offline and degraded sites only.

Never present a guess as a measurement

A plan is only useful if the reader can tell which numbers to trust.

• A leg with no known road route is estimated from straight-line distance, prefixed ≈, coloured amber, and counted in the plan header.
• A leg with no road route at all is flagged, and the day says to confirm the boat or ferry.
• A site with no pin is placed at its town's centre and says so — a site nobody geotagged is often the awkward one, so the guess is worst exactly where it matters most.
• A crew base resolved from an address is marked differently from one guessed from the zone.
• A site that cannot be scheduled is deferred with a reason, never silently dropped.
• The map line is only drawn when it is real. Each day carries the routing service's own road geometry for that exact stop order. Where routing fails, the map shows numbered markers and no line, rather than a straight one that would misrepresent both the distance and the shape.
• Every day has an Open in Google Maps link the crew can navigate with on their own phone.

Islands, and where the boat leaves from

An island site has no road route, and a straight line across open water is not a journey anybody makes. A crew drives to a port and crosses — so the port is the routable point. Road legs are costed to the pier, the crossing is access time on top, and the site keeps its own coordinate so the map still pins the school where the school is. The map draws the road to the pier, a marker for the transfer, and a dotted sea leg out to the site — dotted because it is a boat, not a road.

Ports attach at two granularities, because the real ones differ: an island municipality is served from a mainland port, while island sites inside a mainland town carry their own.

Field knowledge

Terrain belongs to a place, not to each site in it — a steep, muddy municipality is steep and muddy for everything in it.

• Locality profiles — per municipality: terrain, road surface, whether rain changes access, and a free note. Only the awkward towns need a row.
• Site access — per site, exceptions only: the island barangay, the long walk in, the gate whose key the barangay captain keeps.
• Stopovers — where a crew can actually sleep. The planner may overnight only at a recorded stopover or at base, because a map centroid is a coordinate, not a hotel.

Every AI feature is hybrid: deterministic heuristics compute the numbers, and the model classifies or narrates on top. Every one degrades gracefully — on any failure the feature still renders, just without the prose. No screen goes blank because the model is unavailable.

The assistant

A floating widget on every screen, whose behaviour changes by role.

Where else the AI appears

• Outage briefings — dispatch guidance layered on the geographic clustering.
• NOC Daily narrative — the day's briefing in plain language.
• Dashboard insights — narrated deltas over fleet aggregates.
• Site behaviour interpretation — what a site's rhythm means, in words.
• Ticket triage — suggested category, severity, route and a confidence score.
• Schedule tag classification — assigning the 24/7, scheduled or standard hold rule.
• Provider cross-check — the NMS-versus-cloud discrepancy call that keeps false tickets down.
• Route plan adjustment and day briefs — bounded and re-validated, never authoritative.
• Release notes — drafted from commit messages, then edited and published by a human.

A platform that depends on a model needs to know what that model costs and whether it is doing anything useful. Six screens.

Every model call in the estate passes through one metered wrapper. It checks the budget before spending and records tokens, cost, feature label and user after. Limits are stored in the database and edited in the UI, so a change applies on the very next call with no redeploy, and an alert badge in the app header lights up at a configurable percentage. The ledger is shared with the sibling internal-tools application, so the spend figure is the true one across both rather than two half-pictures.

• CSV and XLSX export on data tables throughout the app, loaded only when used so it never slows the rest of the interface.
• Headless capture — a route that renders the report card with no app chrome, so a scripted browser can screenshot it deterministically for batch generation.
• Shared site picker, scoped by project and role, used by every report.

The acceptance and compliance paperwork surrounding each site, in four tabs: Form, Attachment, Monthly, Renewal.

Acceptance (UAT) forms

Per site: customer premise equipment and SSID configuration, access points, link technology and ethernet ports, solar panel, battery and circuit protection checks, captive portal and signage approval, NMS integration checks, security checks including blocked pages and DNS configuration, modem and per-AP bandwidth tests, and an overall pass verdict — signed off by the service provider and DICT representatives.

Monthly DICT reports

Per site per month: per-AP download and upload speed measurements (two runs plus averages), contracted bandwidth, remarks, prepared-by and DICT representative details, and attached photo evidence in defined slots.

Renewal forms

Per site per year: SD-WAN router model, satellite kit identifier and antenna location, SSID, per-AP model and location, and attachments.

Across all three

• Versioning — every form keeps a numbered version history with the user behind each change.
• Generated documents — DOCX output per form and per version, stored with signed access.
• Preview screens — read the generated form and its attachments in the browser before shipping it.
• Coverage tables — which sites have a form, a monthly report, a renewal or contacts, and which do not.

Four surfaces that need no login, and two screens that keep them honest.

• Observer — the no-login operations view: site counts, online percentage, online-percentage-by-project trend, project rail, per-project uptime. Deliberately screenshot-level metrics only — never project secrets, end users, traffic analytics or device detail.
• Public helpdesk board — the same interface as the internal board, fed a sanitised feed: no assignee, no activity log, no assignment history, no “completed by”. A stakeholder can look up a site and see its status without seeing who inside the organisation touched it.
• This wiki — the public operations handbook: the daily loop, org chart, role guides, this atlas, and the full list of URLs.
• Changelog — only published releases reach it.

Public route registry

Public routes are defined in one place that both the middleware and the admin visibility page read — two copies of a security boundary is how you end up with a page that confidently reports something is private while the middleware happily serves it. Because matching is by prefix, the admin page enumerates what actually resolves under each rule and states the reason each route is deliberately open.

Guest book and access log

A short sign-in card before the public boards, asking who is reading. Everything behind it is public either way, so it is an ask, not an access control — and it is built to say so. It fails open: a network or database problem lets the visitor through, because refusing to show a public government board over a logging hiccup is the worse outcome. It asks once per browser and remembers. The record that actually counts is written server-side for every unauthenticated request, so it cannot be skipped. An admin map plots the visitors who granted browser geolocation, and counts the rest in the caption rather than dropping them.

Authentication

Signed tokens in httpOnly cookies — a short-lived access token and a longer refresh token, hashed passwords and rate-limited login. Expired access tokens are refreshed transparently, so a lapsed token never logs a working operator out mid-shift. First login forces a password reset, and a missing profile name is captured once, one prompt at a time.

Roles & scoping

Coordinators, NOC operators, IT and installers resolve access through a project join; DICT is pinned to a single project; installers are additionally site-scoped. NOC operators carry a primary project as an accountability marker on top of their broader access, so they can still cover for each other.

View-as

A superadmin can look through another account's exact permissions to reproduce what a user is reporting. The viewed identity is layered on top of their own session rather than replacing it, and it is enforced read-only at a single choke point rather than by auditing every write path. A banner makes the state impossible to miss, and the real session is re-verified on every request — so demoting or archiving someone ends their active views immediately.

Audit logging

Every mutating request is recorded with actor, action, target, the fields that changed with readable labels, and which system it came from. Surfaced with a per-user activity drill-down, breakdowns and page-view tracking.

User management

Create, edit, archive and restore users; multi-project assignment; generated passwords; an inactive-user cleanup panel; and role-appropriate project pickers. Superadmin only, by design.

Vendors

• Ruijie Cloud — devices, groups, uptime, traffic and users, with the token lifecycle managed for you.
• Huawei — token exchange and device data.
• Omada (TP-Link) — sites and device alert logs.

Data collection

Analytics, reporting and summary endpoints all read from the platform's own database, never live from a vendor. A separate scheduled service populates and refreshes it — device and group collection, daily and hourly uptime snapshots, traffic snapshots and rollups, user activity and deduplicated unique-user summaries, and a weekly site-behaviour recompute. Those endpoints sit outside session auth and are guarded by a shared secret; jobs are logged, and one project per request keeps every call well inside the platform's request timeout.

Releases

Every deployment records a release automatically as a draft. A superadmin generates notes from the commit messages, edits them, and publishes; only published releases reach the public changelog. A “What's New” button in the header marks releases as seen, per user.

Also

• Notifications — an in-app feed with read and unread state, scoped by project.
• Neural Graph — a 3D view of the codebase's own structure, with several layouts and render controls. In live mode it streams real activity through the graph.
• Caching on the public endpoints, so a shared link cannot become a load generator.

• Semantic colour tokens throughout — no hardcoded colours anywhere, defined once in the global stylesheet.
• Light, dark and system theming, remembered. Dark mode is a cool slate, deliberately not black.
• An elevation ladder — sidebar, background, card, accent — building depth with surfaces and hairlines rather than heavy shadows.
• Consistent iconography through one shared badge primitive.
• Motion that respects the reader — entrance animations, hover lift and animated counters are all gated behind the reduced-motion preference, so anyone who asks for a still interface gets one.
• Loading as communication — loaders that narrate what is actually happening (securing session, revoking tokens, generating report) rather than a bare spinner.
• Responsive layout, a collapsible project sidebar, and cached queries for fast repeat navigation.

Every named feature on this page, alphabetically. Use it to answer “does it do X?” without reading top to bottom.