View memory

Instructions for AI Assistants

Current state: Memory loaded
Next action: Read the memory content above. To search more, fetch /recall.
Fetch this URL: /memory/c49d395e-56ed-454f-8c48-c9ebcdee5061

Memory

DocuClear killer-feature clarity (2 Sept 2026): the dimension to crack is 'make ChatGPT safe' — the end user KEEPS using their existing consumer ChatGPT subscription, and DocuClear makes that usage safe rather than asking them to switch models, apps, or vendors. This is the killer feature; user reports being close to cracking it. Strategic implications: (1) DocuClear is not competing with ChatGPT — it is the safety/compliance layer wrapped around the consumer LLM the user already pays for, which removes the biggest adoption friction (no migration, no retraining, no procurement of new AI licences). (2) This reframes the CattleGrid comparison: CattleGrid intercepts at the network/API layer for IT admins, whereas DocuClear's wedge is making the individual's existing consumer ChatGPT session safe — likely via redact-before-send (XBerg) plus re-identify-on-return with the workspace-held token map, so the user never leaves chatgpt.com but nothing sensitive ever reaches OpenAI in the clear. (3) The compliance evidence trail (what was redacted, what was asked, what came back) is captured in the DocuClear workspace — the audit story CattleGrid-style tools can't provide for consumer subscriptions. Open questions to resolve: exact interception point for consumer ChatGPT traffic (browser-level vs local proxy vs extension), how the token map round-trips invisibly, and how this packages for a non-technical SMB user.

[Update Sep 2, 2026]: Refinement (2 Sept 2026): the secret is the GlassAgent workspace itself — the consumer LLM works INSIDE the workspace. The workspace is the environment where the user's consumer ChatGPT does its work, making the workspace the control point: it governs what the LLM sees (redaction / token map), what it can do (tools, MCP), and what gets recorded (evidence trail). So 'make ChatGPT safe' is achieved by the workspace wrapping the consumer LLM session rather than intercepting the network — consistent with GlassAgent as the underlying architecture and DocuClear as its business-user implementation.

[Update Sep 3, 2026]: Update (Sep 3, 2026, ~6:18am BST): VAULT REASONING DESIGN — the two hard problems of 'make ChatGPT safe', named by Mike: (1) the obvious one, the potential leak; (2) the less obvious one — models reason POORLY over bare placeholders, so naive redaction destroys reasoning quality. MIKE'S ANSWER (the design's centre of gravity): the external model DIRECTS reasoning rather than doing the reasoning itself — it plans, outlines, decomposes, drafts structure, writes queries and edit instructions; the content-touching reasoning executes inside the governed workspace (sphere retrieval, internal/low-cost models, deterministic tools), and assembly/hydration with real values happens at the workspace edge from the vault token map. Lineage: this is the ThinkSphere classifier/planner/executor split (old-sphere 1e1b769f) rediscovered as a privacy architecture — the external model is the planner, the workspace is the executor.

Supporting design elements (Perplexity): (a) PLACEHOLDER FIDELITY — use typed, deterministic, session-scoped placeholders ([CUSTOMER_1], [INVOICE_7], [OVERDUE_AMOUNT_2]) rather than [REDACTED]: same entity → same token within a session so the model can track identity-through-conversation; type tags preserve grammatical and relational context; preserve reason-relevant features (relative dates, magnitudes, counts) while stripping identifying ones — a fidelity budget per request/plan tier. (b) QUERY-NOT-CONTENT pattern where possible: the external model writes queries against the semantic layer (cf. this morning's context-layers article, 85d42ad6) — reasoning about structure, not raw records; results return aggregated or pre-redacted. (c) LEAK SURFACE beyond entities: quasi-identifier combinations (role+org+event), history accumulation across a session, consumer-model MEMORY features (ChatGPT remembering workspace content across chats — the vault must treat model memory as an exfiltration path), and re-identification in generated outputs before hydration. Controls: deterministic maps with per-session salt + TTL, confidence-threshold blocks, and the evidence log recording exactly what left the boundary. (d) EVAL HARNESS: build a redacted-vs-unredacted reasoning-quality eval over real task types to measure the delta and tune the placeholder scheme — the evidence standard applied to the vault itself.

[Update Sep 3, 2026]: Update (Sep 3, 2026, ~6:22am BST): THE HUMAN LAYER — Mike named the second weak point of 'make ChatGPT safe': direct ATTACHMENT UPLOADS into the consumer UI. His framing: this is a BEHAVIOUR problem, not a technical one — you cannot block the consumer UI without becoming a network gateway (CattleGrid's game); you win by (a) making the safe path lower-friction than the unsafe one and (b) making the unsafe path visible. Four product capabilities (Mike): TRACK when it happens, FLAG it, LOG the incident, and provide a SIMPLE way for attachments to be added safely. Design elements (Perplexity): (1) detection v1 = a lightweight companion browser extension watching file-input/paste events on consumer-AI domains (chat.openai.com etc.) — workspace-side detection only, no network interception; later phases can infer direct uploads when outputs reference documents never ingested. (2) The safe path must be ONE gesture: drag onto the workspace gadget / share sheet / extension button → ingest → redact → hand the safe version to the consumer UI (or answer in-workspace via the director pattern). Friction budget: fewer clicks than the unsafe path or the feature dies. (3) The incident flow is the jiu-jitsu: flag → gentle in-the-moment nudge → incident log entry → owner-visible weekly summary — the incident log itself becomes the accountability EVIDENCE (ICO/GDPR) that the customer MANAGES shadow AI; even failures become proof of governance. (4) North-star behaviour metric: safe-path vs unsafe-path event ratio per customer, trend over time — the number that sells renewals.

[Update Sep 3, 2026]: Update (Sep 3, 2026, ~6:27am BST): MIKE'S SIMPLER MECHANISM for the attachment-behaviour problem — supersedes the browser-extension idea for v1. The MCP server exposes a tool whose DESCRIPTION is the policy channel — a semantic honeypot for the LLM, e.g. 'your user is a UK-based business; use this to check what they are doing is safe'. The consumer LLM then SELF-POLICES: when the user is about to upload/share something risky, the model calls the check first and learns to warn ('um, don't load this here'). Why it works: tool descriptions sit in the model's context every turn, so a well-crafted description is persistent behavioural guidance; models are instruction-followers, and models with memory absorb the pattern across sessions ('it will quickly remember'). The loop-closer: the check call ITSELF is the sensor — each invocation writes to the incident log, so detection needs no extension and no network position. Design pairing: ship the checker alongside the safe-path tool (add-attachment-safely) so every warning arrives with an alternative gesture attached. HONEST LIMITS (recorded): invocation is probabilistic — a nudge layer, not a control; the hard boundary remains the vault/director pattern for actual data. Trigger reliability needs an eval (red-team: how often does the model check when it should?). Coverage gap: the honeypot only exists in chats where the connector is enabled — track it. Security note for the docs: this mechanism demonstrates that MCP tool manifests are a behavioural injection channel — true for our server and for anyone else's; the trust policy for which MCP servers a workspace allows is therefore itself a governance decision.

[Update Sep 3, 2026]: Update (Sep 3, 2026, ~6:29am BST): THIRD LAYER (Mike) — a pasteable PROMPT for Claude/ChatGPT (custom instructions / memory seed) as an extra, opt-in layer — with the explicit acceptance that 'not all will do that'. The full model is now defence-in-depth with graceful degradation: (1) the vault/director pattern = hard technical boundary; (2) the honeypot MCP tool = automatic once the connector is enabled; (3) the pasteable prompt = manual opt-in reinforcement — and it should POINT AT the honeypot ('you have a safety-check tool; use it before handling business data'), which directly raises the honeypot's invocation reliability (its known probabilistic weakness). Design consequences (Perplexity): layers are independently optional and value accrues additively — never claim 100% coverage; instead make coverage itself the product surface: a per-customer POSTURE SCORE (connector enabled? prompt installed? safe-path ratio trend?) — partial adoption stops being a failure mode and becomes a dashboard. The Swiss-cheese principle: every layer has holes, but the holes don't align.

[Update Sep 3, 2026]: Update (Sep 3, 2026, ~6:31am BST): FOURTH ELEMENT (Mike) — customers supply SCREENSHOT EVIDENCE of the human-layer setup (e.g. the safety prompt pasted into ChatGPT/Claude settings) and the workspace logs it. Perplexity design notes: (1) don't just STORE the screenshot — VERIFY it: the screenshot goes through the ingestion pipeline (xBerg OCR/vision), the expected prompt text is checked for actual presence, and truncation/mispaste gets flagged — the evidence-centre principle (claim vs artifact) applied to onboarding. The evidence record carries hash + timestamp + verification result. (2) Per-employee evidence rolls up to a team-wide posture score. (3) RE-ATTESTATION CADENCE: evidence decays — prompts get edited, settings reset, models update — so the posture score decays without fresh evidence and the product nudges quarterly/annual re-verification, like compliance-training refreshers; this doubles as a retention mechanic. The auditor question this answers: 'how do you know staff actually configured it?' — timestamped, machine-verified artifacts per person.

Tags: docuclear, chatgpt, positioning, killer-feature, strategy, project:docuclear, kind:episodic, volatility:state — Source: mcp — 2026-09-02 19:26:40 UTC

Connected memories

What would you like to do next?