Risks in Dependency Graphs Can't Be Guessed by Models Alone

Last week, I took two students to organize the runtime environment for a small visual annotation tool. Requirements were in Feishu (Lark), code in the repo, and outsourced annotations plus two vendors were also in the docs. I first asked a chatbot to summarize risks. It wrote smoothly, saying "mainly personnel scheduling." Checked the next day, and the actual blockers were expired test certificates and vendor contract expirations. In principle, the problem isn't that the model isn't smart enough—it's that the context is too fragmented.

So I started trying Lenexus. It puts systems, vendors, personnel, and assets into a dependency graph, then uses a deterministic risk engine and an AI layer for judgment. Need to understand a few concepts here. A dependency graph draws entities as nodes and relationships as edges, e.g., "Service A calls Database B." The deterministic risk engine calculates based on preset rules, like single-vendor reliance or lack of backups. The AI layer acts more like a translator, turning paths into human-readable explanations.

On day one, I only logged one lab annotation platform: code repo, GPU servers, Feishu docs, outsourcing team, two vendors, test certs. The UI is a canvas; find nodes by entity category on the left, click to see relationships. I got stuck for over twenty minutes—not because the tool is complex, but because entities weren't cleanly separated. Is the outsourcing team "personnel" or "service"? Are certs "assets" or "risk items"? Stuffing everything into notes makes the graph blurry.

By day three, I started adding rules. Critical paths must have backups, single vendors get flagged red, and if an approver is unavailable for two consecutive weeks, it prompts a blockage. This reminded me of an arXiv paper on LLM Agent dependencies and execution graphs. It breaks execution traces into flat features and dependency features, normalizing dependency blocks by run length. This idea helps me: longer flows mean more nodes, naturally looking riskier. Without normalization, AI might misread "long" as "dangerous." I encountered similar issues in Lenexus—a path from requirement to delivery was auto-flagged high-risk, later found to just pass through three low-priority docs.

A week later, I had the two students do the same task. One asked the chatbot directly: "What are the risks for this annotation platform?" The other entered entities and relationships first, then let the AI layer summarize. The former is good for group chats but lacks traceability. The latter lets you click nodes to see which edge triggered a rule. My testing shows the difference isn't intelligence, it's auditability. Rainbird's article on financial scenarios says deterministic engines make main judgments while LLMs act as interface layers. This is key for risk tools.

However, it's not for everyone. Pros: Clear paths, rules preserve team experience, AI doesn't guess from scratch. Cons: Initial data entry is annoying; Chinese abbreviations, project codes, and synonyms cause confusion; large graphs turn the canvas into a tangled mess. It's also not for people who just want to dump a doc and get an instant risk report. My conclusion: depends. If you already have asset lists, process owners, and rule awareness, it saves a lot of arguing. If your team hasn't agreed on "who depends on whom," it just makes chaos look prettier.

I haven't connected production data this week.

---

📌 Compiled from Hacker News, original article: https://lenexux.com/welcome

Copyright belongs to the original authors. This is a compilation and independent analysis based on public reports.