Memory
THE COMPLIANCE ENABLER — core product component (Mike, Sep 3, 2026, ~6:42am BST): 'It needs to be deterministic but agent-run — it's not about saying no, it's about checking obligations and finding a way to say: yes, we do it like this.' DESIGN SYNTHESIS (Perplexity): (1) DETERMINISTIC CORE — the July compliance-engine blueprint (old-sphere f1fab026): versioned regulatory graph + versioned customer snapshot → fixed outputs, replayable, explainable, evidence-grade auditability. MVP runs on the policy-lookup-table substrate (MVP item 5, D1); graduates to the SurrealDB graph — this is trigger (a) from the timing decision (a092abb2) beginning to stir. (2) AGENT-RUN SHELL — an agent drives the loop: gather facts → invoke the deterministic evaluation → when blocked, SEARCH the obligation graph for compliant configurations → propose the path → human approval via gatekeeper → decision trace written to the Artifacts evidence store. The agent navigates and assembles; the machine determines. Pure rules can only say no; pure agents confabulate law — the pairing makes every 'yes' reconstructible. (3) This is the tagline made functional ('compliance shouldn't be a tax, it should be an enabler' — 2a6499a7) and the Evidence Bay pillar operationalised. (4) Eval discipline applies: deterministic evaluation means the same input always produces the same verdict — the product can PUBLISH its accuracy rather than assert it. (5) CattleGrid contrast: their category intercepts and refuses; the enabler finds the compliant path — 'they stop the leak; DocuClear does the work safely and proves it' (48bc84f0).
Tags: docuclear, compliance-enabler, deterministic, agent-run, obligations, architecture, core-component, volatility:state, project:docuclear, kind:episodic — Source: mcp — 2026-09-03 05:42:33 UTC