# AI Systems Evidence Library Anonymised case files showing specific product pressure, system decisions, and the capabilities those decisions demonstrate. - **Canonical URL:** https://vidhata.me/evidence - **Author:** Vidhatanand V. (Vid) - **Role:** Fractional CTO and AI Systems Architect ## 01. The assistant that had to know when not to help **Domain:** High-stakes conversational AI **The pressure:** Route multilingual, sensitive conversations without turning helpfulness into harm. **The system decision:** A judgement model selects a narrow specialist response; deterministic policy controls consent, repetition, escalation, and intervention boundaries. **What it demonstrates:** Trustworthy AI, Agent routing, Consent architecture ## 02. The marketing system that tried to explain why **Domain:** AI-native growth platform **The pressure:** Convert behavioural events into useful intent without allowing temporary assumptions to become permanent truth. **The system decision:** Topics became first-class objects; memories carry source, status and confidence; recommendations expose reasons and remain reviewable. **What it demonstrates:** Data architecture, Explainable AI, Personalisation ## 03. The camera that was allowed to stop the line **Domain:** Industrial computer vision **The pressure:** A false pass releases a bad unit; a false fail stops production. Camera, model, controls and operator state all matter. **The system decision:** Controlled capture, thresholds, PLC interlocks, evidence records, operator feedback, and fail-safe states surround the model. **What it demonstrates:** Edge AI, Fail-safe design, Industrial integration ## 04. The debate engine that planned interruption before performance **Domain:** Multi-agent media system **The pressure:** Create convincing multi-speaker media without collapsing research, personality, turn-taking, direction and animation into one prompt. **The system decision:** Independent research agents, a timeline compiler, interruption logic, a show director, and deterministic render contracts divide creative judgement from production execution. **What it demonstrates:** Multi-agent systems, Temporal orchestration, Creative tooling ## 05. The private model stack built around the machine **Domain:** Local AI infrastructure **The pressure:** Run useful coding, image, voice and media workloads locally on constrained Apple Silicon while retaining cloud escalation. **The system decision:** Capability routing, quantised model tiers, reusable local APIs, reproducible job manifests, and cloud burst paths keep the stack swappable. **What it demonstrates:** Local inference, Model routing, Cost control ## 06. The diagram pipeline that refused to confuse passing with correct **Domain:** Deterministic visual AI **The pressure:** Generate hundreds of SVG figures that are readable, non-leaky, and faithful, not merely valid files that satisfy superficial checks. **The system decision:** Separate semantic planning, deterministic geometry validation, visual critique, protected findings, and human acceptance into explicit gates. **What it demonstrates:** Evaluation systems, SVG pipelines, Quality governance ## 07. The planner that could explain every recommendation **Domain:** Evidence-led quantitative system **The pressure:** Produce culturally useful plans across age, pregnancy stage, nutrition, safety, allergens, texture, rotation and real household constraints. **The system decision:** Versioned knowledge, hard eligibility rules, auditable scoring, provenance, golden cases, and explicit fallbacks precede generative presentation. **What it demonstrates:** Decision systems, Knowledge modelling, Safety rules ## 08. The six-hour job that did not lose five hours **Domain:** Durable creative workflow **The pressure:** Long AI jobs fail across machines, providers and steps; naïve orchestration restarts expensive work and loses artefacts. **The system decision:** Idempotent stages, checkpoints, resumable queues, cancellation, retry policy and first-class artefacts make interruption survivable. **What it demonstrates:** Durable execution, Queue design, Resumability ## 09. The voice loop that treated latency as product behaviour **Domain:** Realtime voice platform **The pressure:** A conversational interface must react before a complete transcript while avoiding accidental interruption and incoherent state. **The system decision:** Streaming recognition, partial-intent confidence, barge-in policy, turn state, cancellable synthesis and traceable fallbacks form one loop. **What it demonstrates:** Realtime systems, Voice UX, State machines ## 10. The product that did not hard-code its intelligence **Domain:** Capability-first software **The pressure:** AI products inherit vendor churn when product logic, tool use and provider-specific APIs are fused together. **The system decision:** Typed capability contracts, provider adapters, evaluation fixtures, budgets and fallbacks isolate product behaviour from model vendors. **What it demonstrates:** Platform design, Provider abstraction, Testability ## 11. The studio that turned a narrative into inspectable production state **Domain:** Computational-media pipeline **The pressure:** Automated media loses coherence when story, shots, assets, voice, motion, music and export are generated as disconnected outputs. **The system decision:** A canonical timeline links narrative beats, assets, performance cues, provenance, render jobs and QC into an editable production graph. **What it demonstrates:** Media systems, Asset provenance, Pipeline design ## 12. The agent platform whose actions could be reconstructed **Domain:** Product operating system **The pressure:** Multi-agent products become unmanageable when decisions, tool calls, costs, approvals, artefacts and failures disappear into logs. **The system decision:** Append-only events, correlation IDs, addressable artefacts, approvals, health views and stable APIs expose operational state to people and future interfaces. **What it demonstrates:** Observability, Agent operations, Human control ## 13. The interface that was compiled but not trusted **Domain:** Adaptive operational interfaces **The pressure:** Operational teams need different views over the same data and actions, but arbitrary generated interfaces can bypass permissions, confirmations, and audit obligations. **The system decision:** Versioned capabilities, skills, policies, approved components, brand rules, and scoped private intent compile into a validated manifest. Cached manifests render deterministically, while side effects pass through explicit confirmation, undo, and audit controls. **What it demonstrates:** Compiler architecture, Policy engines, Adaptive UI, Action governance ## 14. The tutor that began with a dependency graph **Domain:** Adaptive learning systems **The pressure:** A conversational tutor can explain a mistake without identifying the prerequisite that caused it. Generated questions can also look varied while repeating the same reasoning or carrying an invalid solution. **The system decision:** Model the curriculum as concepts and typed prerequisite edges; preserve responses as append-only evidence; separate authoring artefacts from assessable content; use recursive root-gap diagnosis, symbolic verification, novelty gates, and learner state designed for mastery and revision scheduling. **What it demonstrates:** Knowledge graphs, Adaptive learning, Symbolic verification, Assessment design ## 15. The documentation system that changed only what the code changed **Domain:** Developer documentation systems **The pressure:** Regenerating every document after every code change is expensive and destructive. It overwrites human judgement, pulls irrelevant files into model context, and makes reviewers search for the few sections that actually changed. **The system decision:** Keep source repositories read-only, store documentation separately, map code deltas to affected documents, preserve marked human-owned sections, redact likely secrets before prompt construction, and validate generated structure, links, provenance, and review state. **What it demonstrates:** Developer tooling, Change impact analysis, Content provenance, Safe automation ## 16. The training room that kept working without a network **Domain:** Offline workforce training **The pressure:** A worker may move through physical stations where connectivity is intermittent, yet assignments, content versions, QR checkpoints, assessments, supervisor help, and certificates still need a coherent history. **The system decision:** Package each assigned journey for local use, record progress as an event ledger, synchronise through idempotent operations, keep API, worker, administration, mobile, and object storage as explicit services, and test role-sensitive actions against real seeded infrastructure. **What it demonstrates:** Offline-first mobile, Event synchronisation, Training workflows, Integration testing ## 17. The video system that had to understand order, not just objects **Domain:** Temporal computer vision **The pressure:** A process can fail because a step was skipped, late, out of order, or sustained for too little time. Missed detections and occlusion can look identical to real non-compliance if every frame is judged in isolation. **The system decision:** Normalise model outputs into canonical detections and entity state, then compile versioned sequence, temporal, and negative rules with missing-frame tolerance, debounce, hysteresis, and cooldowns. Preserve a decision trace and the supporting media for human review. **What it demonstrates:** Temporal reasoning, Rule engines, Explainable vision, Model adapters ## 18. The content platform that treated a block as a contract **Domain:** Semantic publishing platforms **The pressure:** Schema changes drift when the content model, generated types, components, fixtures, registry, queries, and renderer evolve independently. A page can compile while structured meaning, brand fidelity, or preview behaviour is already broken. **The system decision:** Use a governed block vocabulary with variants, generate shared types from the content schema, require each block to exist across every implementation layer, centralise content queries, render semantic relationships as structured data, and fail visibly when required source data is missing. **What it demonstrates:** Content modelling, Schema governance, Design systems, Structured data ## 19. The quality plan that preserved the chain from function to control **Domain:** Manufacturing quality planning **The pressure:** A wide quality table hides a deeper graph. Functions fail in specific modes, failures create effects, causes carry occurrence and detection risk, actions change the analysis, and process steps become control-plan characteristics. **The system decision:** Represent functions, failure modes, effects, causes, risks, and actions as typed hierarchical entities; keep versions, release states, confidentiality, and team roles explicit; link process-flow steps to control-plan rows; and surface risk summaries without flattening away their source relationships. **What it demonstrates:** Domain modelling, Risk workflows, Versioned planning, Operational UX ## 20. The backtest that was not allowed to know the future **Domain:** Financial research infrastructure **The pressure:** A strategy can look convincing when universes, fundamentals, mappings, or signals leak information from the future. Honest reruns also become incomparable when features, costs, execution rules, code, and portfolio assumptions drift. **The system decision:** Maintain a separate point-in-time fundamentals ledger, enforce availability and effective-date guards, separate raw data, features, signals, and portfolio results, hash and persist configurations and component versions, simulate costs, slippage, capacity, and risk, and validate with walk-forward and robustness runs while keeping live trading out of scope. **What it demonstrates:** Quantitative research, Point-in-time data, Reproducible simulation, Auditability ## 21. The assistant whose memory could not rewrite the record **Domain:** Sensitive-domain AI architecture **The pressure:** A helpful assistant needs private context and general evidence, yet a model-created memory can be stale, inferred, or wrong. Letting it overwrite canonical family, account, or operational data creates invisible corruption and permission risk. **The system decision:** Keep the domain backend authoritative; expose private state only through curated read-only tools; store AI memory, safety traces, and cost records separately; retrieve private context and general evidence through distinct channels; and fail visibly when required context is unavailable. **What it demonstrates:** Data authority, AI memory, Permission design, Sensitive systems ## 22. The conversation that could not react to unheard words **Domain:** Realtime multi-speaker systems **The pressure:** A speaker can generate faster than audio plays while listeners prepare replies, interrupt, yield, and overlap. If private candidate text enters history early, reactions and replay are based on words that never became part of the conversation. **The system decision:** Separate candidate speech from an audible cursor, model interruption as prepare, commit, cancel, seize, and yield states, persist every consequential transition on one clock, and replay original audio and events instead of regenerating an approximation. **What it demonstrates:** Realtime orchestration, Event sourcing, Turn control, Deterministic replay ## 23. The project room that refused to become a chat transcript **Domain:** AI-assisted project work **The pressure:** When constraints, examples, risks, dependencies, and prior decisions live only in conversation history, each model sees a different version of the problem and useful reasoning disappears after the session. **The system decision:** Represent project context, decisions, tasks, dependencies, and generated outputs as addressable objects; compose prompts from a structured canvas; keep credentials server-side; preserve model provenance; and use database migrations as the shared source of truth across environments. **What it demonstrates:** Knowledge modelling, Multi-model orchestration, Decision provenance, Project systems ## Work with Vid Start with the actual technical pressure: [bring the problem](https://vidhata.me/hire).