{"version":"2026-10-09","sha256":"7cf33804f4a218b26361c24ccad029befaec45b5e4d8bec98218aca5708b872c","scope":"Selected professional experience and applied AI implementations, with source context and scoped verification.","records":[{"key":"ai_case:bounded-control-plane","kind":"ai_case","architecture":["Authenticated role","Permitted tool contract","Bound confirmation","Controlled operation","Reviewable result"],"boundary":"Focused local policy and analytics tests with mocked provider dependencies.","category":"Governance","id":"bounded-control-plane","implementation":"I developed a control plane with role/tool policies, HMAC-bound confirmations, prompt and output filters, provider interfaces and template resolution. An analytics path fixes organisation scope before canonicalisation and cache-key generation, then calls a fixed aggregation interface rather than arbitrary generated SQL.","lesson":"The control must sit outside the prompt. Negative fixtures matter as much as the successful path.","problem":"An assistant that produces useful text should not automatically receive authority to change records or perform an external action.","stack":["TypeScript","Policy contracts","Signed confirmations","SQL aggregation"],"status":"Fresh local tests","summary":"I separate what a model recommends from what its role is allowed to do, using tool policies and confirmations tied to the actual action.","title":"A model can propose an action. Authority decides execution.","verification":"140 control-plane tests, 13 model-tier selection tests and 32 analytics-contract tests passed locally on 9 October 2026. Provider-registry and stream checks use mocked dependencies."},{"key":"ai_case:context-and-generation","kind":"ai_case","architecture":["Registered source material","Task-specific retrieval","Context sufficiency gate","Structured generation","Source-aware review"],"boundary":"Lexical retrieval, context sufficiency and structured-output validation are implemented in separate applications.","category":"Context engineering patterns","id":"context-and-generation","implementation":"I developed paths that assemble requirements, criteria, risks and selected prior material. Project memory and bounded chat history preserve continuity. Source-linked snippets support lexical retrieval. Sufficiency checks and output validation make missing context and malformed results explicit.","lesson":"Context engineering is a selection and responsibility problem. Keep the source of a fact visible after generation.","problem":"Operational archives contain inconsistent and irrelevant material. Passing everything into a prompt obscures requirements and supporting facts.","stack":["Python","TypeScript","Lexical retrieval","Structured validation"],"status":"Source inspected","summary":"I select the context for each task, check whether the sources are sufficient and require a structured output the next role can inspect.","title":"Give the model enough context, not the whole archive.","verification":"Context and generation code inspected across separate applications. The implementations preserve task requirements, source sufficiency and structured output contracts."},{"key":"ai_case:public-reference-shell","kind":"ai_case","architecture":["Local reference server","Defined action policies","Human decision boundary","Append-only records","Provider or explicit no-provider response"],"boundary":"A runnable local reference implementation using synthetic inputs and mocked providers, with owner-directed code review and published tests.","category":"Reproducible public work","id":"public-reference-shell","implementation":"I defined an architecture with replaceable model providers, local file memory, explicit human review for consequential actions and append-only audit records. The public shell implements selected mechanisms with synthetic demonstration data. Its implementation and assessment were produced with coding agents under my direction. Review exposed a malformed risk-input boundary. I directed a fail-closed fix and regression checks before publishing it.","lesson":"Make a useful claim small enough to reproduce. Simulations, inventory counts and model usage remain separate from observed operational value.","problem":"A description of safe agent behaviour is difficult to trust without runnable code, failure checks and explicit limits that another person can inspect.","references":[{"label":"Public reference shell and setup","url":"https://github.com/Haris88m/servari-open"},{"label":"Architecture, simulations and limits","url":"https://github.com/Haris88m/agentic-os-audit"}],"stack":["Python","Standard-library server","Deterministic tests","Mocked provider contracts"],"status":"Fresh local tests","summary":"I published a local-first reference shell so another person can inspect the action boundaries and see how provider selection behaves.","title":"A reference implementation you can inspect and run.","verification":"The public implementation passed 384 local tests on 9 October 2026, including 224 added numeric-domain and CLI regressions, plus eight verifier checks. Published CI also completed the Python suite, verifier and UI build. The tests use synthetic fixtures and mocked providers."},{"key":"ai_case:receipt-bound-workflows","kind":"ai_case","architecture":["Validated preparation","Authorised action","Case-bound receipt","Integrity verification","Recorded completion"],"boundary":"Local workflow tests cover case identity, file integrity and state transitions using temporary fixtures.","category":"Workflow integrity","id":"receipt-bound-workflows","implementation":"I developed a persistent workflow requiring a validated receipt associated with the same case. It checks the stored SHA-256 hash before recording completion and rejects missing, unrelated or changed receipts. Source-linked claim checks remain a separate layer so evidence acceptance is not confused with execution success.","lesson":"Define completion through evidence another person can inspect, not the confidence of the last message.","problem":"A workflow can look finished after an attempted action without valid confirmation. Later decisions may then rely on a false completion record.","stack":["Python","SQLite","SHA-256","State transitions"],"status":"Fresh local tests","summary":"I require a matching receipt and file-integrity check before the workflow records an action as completed.","title":"Attempted is not completed.","verification":"18 application-engine tests passed locally on 9 October 2026 using in-memory databases and temporary receipts. Those tests submitted no real applications."},{"key":"ai_case:reliable-ingestion","kind":"ai_case","architecture":["Source adapters","Bounded attempts","Retrieval provenance","Canonical matching","Health records and updates"],"boundary":"Source-isolated ingestion with deadlines, provenance and health records. Cancellation and identifier fallback are the next reliability checks.","category":"Reliability","id":"reliable-ingestion","implementation":"I directed a multi-source ingestion path with independent settled outcomes, per-source 30-second deadlines, isolated diagnostics and source-health records. Adapter logic handles an upstream API version and records parser and retrieval provenance. Canonical external identifiers support matching and update/backfill behaviour.","lesson":"Diagnose each source separately. Keep incomplete records and upstream failures visible rather than reporting a misleading clean aggregate.","problem":"Upstream sources change formats, fail independently and return incomplete records. A slow source can stall discovery and inconsistent identifiers can duplicate records.","stack":["TypeScript","Edge functions","API adapters","Data normalisation"],"status":"Source inspected","summary":"Independent source processing, deadline handling, stable identifiers and health records support multi-source ingestion.","title":"A broken source should not block every other source.","verification":"Current source inspected on 9 October 2026, including per-source deadlines, parser provenance, source health and canonical matching."},{"key":"ai_case:specialist-orchestration","kind":"ai_case","architecture":["Shared task context","Three bounded branches","Settled results and failures","Dependent synthesis","Complete or partial result"],"boundary":"Three specialist analyses and a separate synthesis stage, implemented with provider abstraction and explicit partial results.","category":"Orchestration","id":"specialist-orchestration","implementation":"I directed an explicit fan-out/fan-in workflow. Three specialists receive shared context and return separate findings. A dependent synthesis combines available results. Fulfilled and rejected branches are handled independently and a partial run remains identifiable.","lesson":"Parallelism only helps if the downstream step knows what it can rely on. A partial result needs a different acceptance decision.","problem":"A complex decision needs several perspectives. One long response makes it difficult to see which analysis completed and which input failed.","stack":["TypeScript","Asynchronous orchestration","Provider abstraction"],"status":"Source inspected","summary":"I built a workflow in which three specialist analyses share the same context and feed a separate synthesis stage. If a branch is incomplete, the next role sees the gap.","title":"Separate the analysis. Keep one accountable decision.","verification":"Orchestration source inspected on 9 October 2026. The implementation handles fulfilled and rejected branches independently before synthesis."}],"total":6,"limit":25}