AI Enterprise SolutionsGPT & Claude

Signos

NOC engineers and enterprise account managers at mobile operators, starting with Azerbaijan’s Azercell, Bakcell and Nar. When a single fiber link fails, engineers drown in hundreds of alarms while hunting for the one root cause, and nobody sees the business impact in time: which enterprise customers are down, which SLAs are about to be breached, and how much revenue and penalty exposure is building up by the minute. Network, contract and revenue data live in separate systems owned by separate teams, so account managers hear about outages from angry customers and finance counts the damage weeks later. Existing NOC and AIOps tools stop at the network layer; no tool today connects an alarm to a contract and a balance sheet. Signos closes that gap with supervised AI agents for network, contracts, finance and customers that work on one shared data layer, turning an alarm storm into a single incident with its full business impact, and proposing actions that humans approve.

Video GitHub

Preliminary score

61.0/ 100Promisingaverage of 2 judges

Value for the user20.5 / 25
A specific problem and a clear outcome from solving it.
Prototype and use of AI13.0 / 30
A working core scenario, and what AI actually contributes to the result.
Quality testing12.0 / 20
Tests, examples of failures, and comparison with the current approach.
Feasibility9.0 / 15
Data requirements, running costs and a clear next step.
Originality6.5 / 10
A meaningful difference from common solutions.

What the judges wrote

GPT-6 AstraPreliminary59/100
Strengths
Your outage workflow connects a specific engineering problem to actionable SLA, financial and customer consequences for clearly identified users. Your design separates deterministic financial calculations from AI explanations and includes human approvals and traceable source records. Your testing report documents concrete authentication, migration and rendering failures, while clearly acknowledging that live AI generation remains unverified.
To improve
Your first priority should be demonstrating a successful live Gemini run through validated output and human approval, showing what AI adds beyond deterministic rules. Extend your testing to varied outage scenarios, incorrect root causes and independently checked SLA calculations, comparing impact-assessment time with the current workflow. Add automated frontend regression tests and concurrent-user checks to complement your backend tests and manual browser checks. For your proposed regional pilot, specify data access and joining requirements, subscriber-data protections, and inference, hosting and integration costs rather than only license pricing.
Claude Opus 5.5Preliminary63/100
Strengths
Your problem framing is sharp and specific: one fiber cut seen differently by NOC, account/legal and finance, backed by cited alarm-volume and outage-cost figures and a clear Azerbaijani beachhead. Your demo scenario turns 150 alarms into one incident with root-cause link FL-07, an SLA countdown, revenue loss per minute and affected premium subscribers, which makes the cross-team value concrete. Your governance design stands out: role-based approvals, an audit log, an autonomy dial, and the rule that code computes while AI only explains. Your testing write-up is unusually honest, listing real bugs fixed and the gaps you have not verified.
To improve
By your own account, no live Gemini call has ever completed end to end, so the AI's contribution to the result is unproven. Get real structured outputs running and show several examples, including failures. Your testing covers engineering bugs but not the core claim: measure root-cause accuracy and alarm-reduction across several simulated incident types, and compare time-to-impact against today's manual process. Add LLM running-cost estimates per incident, and explain how you would get real alarm, contract and revenue data for the pilot, since everything shown, including per-cell revenue, is synthetic.

The team

2. Aydın Nağıyev
developer
Məhəmməd KərimovLead
developer
1. Emin Quliyev
data

Disclosure

Required by the rules. Judges verify it against the repository.

Models: gemini-3.8-flash
Data: Mock generated working data (No public real data available)
Components: —
Built during the event: Confirmed

Quality testing

What broke (and got fixed) Real bugs found during this process, not hypothetical ones: passlib/bcrypt incompatibility — passlib is unmaintained and crashed against modern bcrypt on startup. Switched to bcrypt directly. A circular foreign key silently failed to apply — Alembic’s autogenerated migration said it succeeded but the sites.uplink_link_id → links constraint was never actually created in Postgres. Caught by alembic check, not by eye. Admin bootstrap created a dead account — EmailStr validation rejects .local as a reserved domain, but the bootstrap code bypassed Pydantic validation, so it silently created an admin that could never log in through the API itself. React “setState during render” in the login page. A real app crash: Next.js 16’s experimental cacheComponents/partialPrefetching flags broke react-leaflet’s map (Cannot read properties of undefined (reading 'appendChild')) — removed those flags. An asymmetric animation bug — the login step transition looked fine going backward but jumped going forward, traced to AnimatePresence’s popLayout mode snapping container height; fixed with a CSS grid-stack approach, verified with direct DOM sampling (not just eyeballing screenshots). What’s NOT tested — the honest gaps No real Gemini call has ever succeeded in this session. Every single agent test — unit tests and my own manual demo runs — either mocked the Gemini client or hit the “API unavailable” fallback path, because there was no working key for almost all of development. There’s a value in .env now, but I have never personally watched a live Gemini call return real structured output and pass Pydantic validation end-to-end. The fallback-to-last-known-output and the “agent unavailable, no fake text” path are verified. The actual generation quality is not. The SSE live-update endpoint (/incidents/{id}/stream) is built and unit-tested on the backend, but the frontend never calls it. The console polls REST every 5 seconds instead. It’s dead code from the frontend’s perspective. No frontend automated tests exist at all. Every frontend check in this session was me driving a browser by hand. A regression after this session would not be caught automatically. The portfolio page recommends “upgrade” for essentially every site in the imported dataset — technically correct given the formula, but it’s because the per-cell revenue figures are synthetic (hash-derived, since the hackathon CSV data had no cells.csv), not because the thresholds were validated against realistic numbers. Don’t read too much into that screen in a demo. No load/production testing — never run with more than the ~100-site dataset, never deployed behind real TLS/a real domain, never tested concurrent multi-user load (only ever had 1–2 browser sessions open at once, and once that actually caused confusing state from both of us clicking simultaneously — not a bug, but a sign multi-operator behavior isn’t something I verified).

Worth 20 of the 100 points.

Running it

There is SETUP.MD in repo to init both frontend and backend. Please use that instructions.

Project ownership

The team keeps the rights to this project. Judges were given access for verification only.