App·Help

How VinTekh works

End-to-end: from a connected source to a recommendation with a rollback plan, in plain language.

1. Discovery (the worker)

A Python discovery worker (deployed as ca-vintekh-pilot-worker on Container Apps) polls each connected source on an interval. For Azure, the worker uses Azure Resource Graph KQL to enumerate every ARM resource, then per-kind enrichment to pull the attributes we care about. It also reads RBAC, Defender assessments, Policy state, Activity Log, and Monitor metrics.

Every connector is read-only by construction — see Read-only model.

2. Normalisation (the worker)

Raw cloud responses get mapped to a normalised schema: NormalizedAccount, NormalizedResource, NormalizedFinding, NormalizedRelationship, NormalizedRoleBinding, NormalizedChangeEvent, NormalizedBusinessService. Vendor-specific fields are preserved in a raw JSONB column for forensic drill-down but never leak into business logic.

3. Persistence

Normalised entities land in PostgreSQL (relational truth). Relationship edges are also lifted into Neo4j for graph queries used in blast-radius and attack-path walks.

4. Investigation orchestration (the web app)

When you start an investigation, the orchestrator:

  1. Identifies the matching playbook for the resource kind + finding shape (12+ playbooks today).
  2. Pulls the evidence the playbook declares it needs (topology 1-hop, change events 24h, related findings on neighbours, RBAC bindings, framework mappings, MITRE techniques).
  3. Builds a system prompt for the LLM with the playbook's rules + the evidence.
  4. Calls the LLM (Azure OpenAI deployment) with strict JSON schema enforcement.
  5. Validates output against deterministic guardrails (G1-G5). If a guard fails, surfaces the violation; never silently coerces.
  6. Persists the result as an Investigation row with linked Recommendations + Evidence + StatusEvents.

5. UI rendering

The Next.js web app renders the investigation result with three explanation tabs (beginner / engineer / architect), facts vs. assumptions vs. unknowns, blast radius, recommendations with rollback, evidence rail, and a comment thread with @mentions.

6. Handoff

From a recommendation card you can push to Slack or ServiceNow. The handoff sends text (recommendation summary + evidence link) — it does not execute changes. Execution stays with your change-management process.

Where the AI sits in the loop

The LLM is the synthesis engine, not the data source. Every fact in the AI output is grounded in something we pulled from the cloud — and every fact carries an evidence_ref so you can verify. We use the LLM for what LLMs are good at (explaining + summarising + ranking) and code for what code is good at (querying + joining + validating).

What's deferred to next tranches

  • Interactive dependency graph viewer (data exists; viewer is roadmap).
  • Identity attack-path walker + viewer.
  • Cost / reliability / performance recommendation modules.
  • SLO + error-budget tracking.
  • War-room incident mode.
  • Conversational NL → graph query assistant.
  • Multi-IdP SSO + SCIM provisioning.

See Platform capabilities and the SERVICE_REGISTRY doc for the full tranche plan.

Browse docs