KOIP - Karabakh Operations & Infrastructure Preservation
Target Users: 1. Corporate Legal & Procurement Teams reviewing complex, high-liability B2B service contracts and vendor SLAs. 2. Telecom & Enterprise B2B Retention Managers losing high-value accounts due to slow, generic customer care. 3. Network Operations Center (NOC) Directors managing mission-critical regional infrastructure in difficult terrains. What Goes Wrong For Them Today: 1. Legal Blindspots & Catastrophic Penalty Exposure (Primary): Reviewing 50+ page vendor and client contracts manually is slow and error-prone. Teams routinely miss asymmetric liability clauses (e.g., hidden 5%/hour downtime penalty terms versus the 0.5% industry standard), exposing companies to massive financial losses. Standard single LLMs hallucinate and fail to debate conflicting legal vs. financial priorities. 2. Impersonal, Generic Customer Churn: When high-value enterprise clients or students face connectivity issues, traditional systems respond with rigid, generic bot scripts or delayed tickets. Without real-time telemetry awareness, companies either lose accounts (up to 25% churn) or bleed margins by offering blind, uncalculated discounts. 3. Rugged Terrain & Critical Infrastructure Delays: In rugged mountain regions (e.g., Karabakh and East Zangezur), fiber cuts take 4–5 hours for physical brigades to reach, risking total communication failure and severe SLA breach penalties.
Preliminary score
- Value for the user15.0 / 25
A specific problem and a clear outcome from solving it.
- Prototype and use of AI15.5 / 30
A working core scenario, and what AI actually contributes to the result.
- Quality testing9.5 / 20
Tests, examples of failures, and comparison with the current approach.
- Feasibility5.5 / 15
Data requirements, running costs and a clear next step.
- Originality5.0 / 10
A meaningful difference from common solutions.
What the judges wrote
- GPT-6 AstraPreliminary55/100
- Strengths
- Your strongest use case is exposing costly SLA clauses before procurement signs, with legal and financial agents addressing different risks. Your reported failures are specific, particularly the missed downtime penalty and excessive compensation, and deterministic discount limits are a sensible safeguard. Connecting retention messages to outage telemetry gives your customer-care module useful operational context.
- To improve
- Your next demonstration should show one complete contract review with source-clause citations, penalty calculations and redlines, explicitly distinguishing live model responses from fallback data. Your testing needs the nine test results and a held-out comparison against single-model and manual review; the claimed error rates and savings are not substantiated by the supplied materials. Your network failover should remain labeled as a simulation until measured on real infrastructure, rather than presented as 0.0 ms recovery. Your feasibility plan should define a narrow pilot, contract-confidentiality controls, API costs and account-level profitability checks beyond a fixed discount cap.
- Claude Opus 5.5Preliminary46/100
- Strengths
- Your contract-audit module targets a real, costly pain: missed asymmetric penalty clauses. Your concrete Clause 14.2 example (5%/hour vs a 0.5% norm, a 2,400 AZN penalty wiping out annual margin) makes that pain tangible. Your failure write-up is specific and useful. The single-LLM approval of a bad contract, discount drift above 40% fixed with a 25% cap, and the simulation race condition fixed with state locking are exactly the kind of evidence judges want. Your setup steps are clear, and a test suite and CI are included.
- To improve
- Your project bundles three unrelated products: contract review, churn SMS and network failover. Pick one workflow, most likely the contract auditor, and prove it end to end on several real-world-style contracts. Your headline numbers (0.0 ms failover, <0.1% consensus error, 18.4% human error, 24,800 ₼/month saved) are not backed by any shown measurement. Replace them with a small labelled test set, for example 20 contracts with known risky clauses, and report single-LLM vs multi-agent recall alongside the failures. Also show which outputs come from GPT-4o-mini and which from canned fallback data. Finally, add running costs per contract, your data sources and a concrete pilot next step.
The team
Huseyn VerdiyevLead
product
Agharahim Hasanov
developer