IRONSTICK← Home

IRONSTICK — The Desktop-AI Bridge

One local bridge, four desktop AIs on equal footing — Claude Desktop / Claude Code, ChatGPT Desktop, Qwen Desktop and Kimi Desktop — plus the built-in IRONSTICK AI chat. What the bridge is, how it is licensed, how it relates to the in-app chat, how to install it, how every access is displayed, what you can do with it — and the complete catalogue of the 175 tools IRONSTICK provides. Windows edition.

1. What the bridge is

The bridge connects your own desktop AI — Claude Desktop (or Claude Code), ChatGPT Desktop, Qwen Desktop or Kimi Desktop — to the running IRONSTICK application on the same computer. The AI can then read your case material through a set of purpose-built tools — chronicles, document full texts, e-mails, deadlines, master data — and work with it at full depth: analyse, cross-check, draft. The connection is strictly local (127.0.0.1); no IRONSTICK server is involved. The data the AI reads is processed under your own subscription with that provider and the provider's terms — see the GDPR data-flow declaration for the full picture.

• Requires the respective desktop application with the user's own account (Anthropic, OpenAI, Qwen or Kimi).
• Works only while IRONSTICK is running — closing the app closes the data source.
• This channel transmits real, unpseudonymized data by design — that is what makes drafting submission-ready templates possible.
• Documents marked secret are invisible to the bridge.
• The cross-chat AI memory is built for long-running proceedings: entries linked to an active case never expire, and every use of an entry refreshes its lifetime — only dead material ages out after a year.
• Write access is deliberately narrow: suggestions land in the Data Consistency Monitor for your review; drafts are handed over into the word processor; nothing is written into your records directly.

1b. Why the bridge?

Because working over a subscription is usually many times cheaper than working over the API. A desktop AI runs on the flat-rate subscription you already hold with the provider; every dialogue, every full-text read, every draft round is covered by it. The same work through IRONSTICK's in-app chat runs on your API key and is billed per token — for long dialogues on large files that adds up quickly.

Where the bridge shines is cost: it is a massive cost reducer for AI dialogues, and the tool of choice whenever documents or larger data holdings are managed and maintained through the AI — reading whole case files, keeping chronicles, protocols and memories current, working through hundreds of exhibits — work that would be prohibitively expensive token by token.

1c. Licensing — four bridges, or the bundle

Each desktop-AI access is its own licensed add-on module:

• Availability is encoded in your signed licence key: only the licensed bridges come into existence — an unlicensed one has no front-end and no tool surface and does not appear in the configuration.
• You can licence a single bridge (just the desktop AI you use) or the bundle of all four — and add more later.
• Licensed bridges may run in parallel; a case can be worked by several desktop AIs at once.

1d. The built-in IRONSTICK AI chat — same model, plus Gemini, no extra licence

IRONSTICK also has its own AI chat built in, and it runs on exactly the same working layer as the bridge — the same tools, the same gates, the same grounding and the same submission-ready drafting. Whatever the bridge can do, the in-app chat can do too. Beyond the four bridge providers it additionally offers Gemini from Google as a provider.

• No extra licence. The in-app chat is integrated in IRONSTICK; it needs no additional bridge module.
• It runs on the providers' API (your own API key), billed per token. Because API rates are somewhat higher than a flat subscription, the in-app chat can be more expensive in daily use than using the bridge together with the provider's own desktop app — where the subscription model is far cheaper.
• In exchange, the API path through IRONSTICK is more tightly supervised and controllable: pseudonymized by the router, consent dialog, audit log and size caps — on the same gates as the bridge.

2. Installation (any of the four)

The flow is the same for every desktop AI; only the download source and the set-up button differ.

1. Install the desktop application and sign in with your own account, then start it once (see the per-provider row below).
2. In IRONSTICK open Configuration → AI configuration → AI with local MCP server (STDIO).
3. Switch "Allow connector access from local desktop AI" ON (the master switch for the whole channel).
4. Optionally switch "Allow navigation by the desktop AI" ON if the AI may also steer the app — open screens, cases and documents, export files. Reading works without it.
5. Click the matching "Set up … Desktop" button. IRONSTICK rolls out its own bridge instance and registers it in that desktop AI by itself — nothing to paste, nothing to type.
6. Start a new conversation (or click "Recycle desktop AI" in the same section to restart it). IRONSTICK then appears among the AI's connectors and the tools below are available in every conversation.

The configuration screen carries the download links and the links to each provider's terms of use and privacy policy.

3. How accesses are displayed in the menu bar

• Consent first. The first time a desktop AI touches data in a program run, IRONSTICK shows a blocking confirmation dialog. Refusing blocks that channel for 10 minutes; approving opens it for the rest of the program run.
• A per-AI logo appears in the top bar next to the CPU/RAM readout during every single tool call and stays lit for 3 seconds after the last call — rapid call series keep it lit continuously. If the symbol is dark, nothing is being read. Each AI has its own mark: the orange Claude starburst, the green OpenAI knot, the violet Qwen chat symbol, the petrol Kimi "K".



• The dropdown at the AI symbol shows what that AI has read in the session: the "working instruction + hallucination prohibition" line (green check while valid, red cross once expired), then per case the flags profile, jurisdiction and digest plus a "documents read r of n" bar.
• The brain symbol appears as soon as the shared AI memory has entries and pulses for 3 seconds whenever any AI channel reads or writes it. Clicking it opens the management dialog; the AI itself can never delete memory.
• Navigation by the AI (opening screens/cases/documents) happens only if its switch is ON — otherwise navigation tools are refused.
• Parallel access: when several licensed AIs work at the same time, the top bar shows one pulsing logo per active AI side by side; every access is always attributed to the AI that made it.

4. The sixteen deterministic hallucination & safety gates

IRONSTICK does not try to educate the connected AI with prompts — it enforces correctness structurally. Sixteen deterministic gates (pure logic, no AI anywhere) sit between the model and your records. Throughout the tool catalogue below, gate-secured tools carry a GATE badge.

5. What you can do with it — examples

Talk to the desktop AI (or the in-app chat) in plain language; it picks the right tools by itself. Typical requests:

6. The complete tool catalogue

These are the 175 tools the bridge currently provides — identical for every connected desktop AI and for the in-app chat. All of them are read-only against your records unless marked otherwise; “suggestion” tools never write directly — their output waits for your approval in the Data Consistency Monitor.

Context & navigation

Finding the right record

Reading a case

Documents & passage search

Judges & court decisions

Five deterministic tools (no AI anywhere) for one question: how does an individual judge or prosecutor decide — what does he take up from the submissions, what does he pass over, how predictable is he? The tools locate and measure; reading the decisions and judging them remains the AI's work, on the full texts. Only incoming documents from a court or a prosecutor's office count as decisions.

OCR re-scan healing — Human-in-the-Loop Micro-Sourcing

When a stored full text turns out to be truncated or ruined by an old OCR run, the AI does not simply live with it — it heals the database, with you as the final authority. It requests a fresh scan; you pick the pages in IRONSTICK (same page picker as document capture); the re-scan is deterministically normalized (watermarks stripped, OCR patterns fixed, spacing equalized) and placed in the scratch space NEXT TO the current database text. The AI then compares both versions passage by passage, keeps whichever is right, fixes only mechanical OCR damage — never rephrasing; numbers, names and amounts stay untouched — and hands the healed version back. IRONSTICK shows it to you in full, and only YOUR click saves it as the new full text.

The step beyond: the lawyer as a precision instrument. The AI does not use IRONSTICK only as a data source — where automatic processing hits physical limits, it deliberately calls on you as a visual precision tool:

• Full capability even with giant files. Where a PDF exceeds any AI context (the bridge enforces hard limits: 10 MB, 90 pages), the process does not end with a useless “file too large” — the AI names the exact spot instead: “page 12, near the top”.
• Focused micro-effort instead of file archaeology. You never comb through a 200-page file. You click the paperclip in the entry IRONSTICK has already opened for you, jump to the named page and type off exactly the three illegible words or figures.
• Direct feedback into the full text. Your transcription is taken over verbatim into the healed version, passes the same acceptance dialog, and the analysis continues seamlessly.

Traditional systems know exactly two states: “success” (whatever the OCR produced, right or wrong) and “error — please process the document manually”. Here the lawyer becomes a micro-tasker for exactly the 0.1 % of a scan the AI cannot resolve with certainty — a symbiosis of AI speed and human eyesight.

E-mail, calendar & deadlines

Persons, institutions & work records

Working rules, formats & memory

Suggestions (review-gated — never write directly)

Scratch space — big content never passes through the AI

A local work area. Any tool call may carry to_scratch: the full result is then written to a scratch file and the AI receives only the path and the size — no preview; and every result above the connector limit (10,000 characters; 20,000 for Claude Desktop and ChatGPT Desktop) goes there automatically, the same way — toolset openers included. Large content flows through the AI's output in NEITHER direction (faster, cheaper, no transcription errors). Scratch paths are directly usable as source_path for deliver_file and update_ki_instruction. The store survives restarts: the AI's own notes, its state register and the read-coverage bookkeeping persist; tool dumps from earlier days are purged at every start, untouched files after 180 days.

The scratch store is a vault. Since September 2026 every file in it is AES-256 encrypted at rest, with the same key derivation as the case database and the document store — nothing the AI writes lies in plain text on the disk. Reading and writing pass only through IRONSTICK's gate; a plain-text file placed into the store by any other route (a file-system tool, a manual copy) is refused, removed and reported to the AI as a rule violation. Files leave the store only through IRONSTICK's export dialog, never to a download folder. Together with the encrypted database, document store and configuration this closes the last gap: no case data lies unencrypted on the user's disk — not even the AI's working files.

No tool shortens its own result. evidence_readfull, read_full_case, read_email_body, open_url (whole statutes and judgments), read_tagesprotokolle, read_person and read_chronik always deliver their content COMPLETE. One central rule decides where it arrives: below the connector limit in the answer, above it as a whole in the scratch file. The AI never has to guess in advance how large a result will be.

Freshness guard: IRONSTICK watches every scratch file. The moment the underlying data changes — a new document or chronicle entry in the dumped case, a calendar or protocol write — or a file simply ages out, its content is replaced by an invalidation notice that tells the AI exactly how to re-fetch it. The AI can never work from silently outdated dumps.

Web, registers & validation

Peer review — hand a piece to ANOTHER desktop AI (Claude ⇄ ChatGPT ⇄ Qwen ⇄ Kimi)

Hand-over & delivery

7. Diligence guards — the bridge supervises the AI's work ethic

Four deterministic diligence guards watch how carefully the connected AI actually works. They are pure bookkeeping and string logic — no AI involved anywhere — so they cannot hallucinate, cost practically nothing, and cannot be talked out of anything:

• Read-coverage guard. When the AI pulls a full-case dump, the preparation files of a case or a full text above the connector limit, the bridge records line by line which ranges it has really read — and keeps that bookkeeping across restarts. As long as gaps remain, every tool answer — searches, grep, everything — carries the exact unread line ranges with a percentage. A claimed “I have read everything” is simply impossible; only a complete read earns the one-time confirmation “COMPLETE — all lines read”, a mathematically provable end of the reading duty — and stamps the reading into the preparation ledger.
• No preview. Any result above the connector limit (10,000 characters; 20,000 for Claude Desktop and ChatGPT Desktop) is written to the scratch store as a whole; the AI receives only a note naming the file, its size and the two continuation commands. Nothing is shown twice, and the AI reads large content where it lives. This holds for every tool — toolset openers included; only the instruction reader and the scratch tools themselves answer directly. And no tool shortens its own result: below the limit it arrives complete in the answer, above it complete in the scratch store.
• Re-delivery guard. If the AI keeps correcting a working file after it was already delivered to you, every further edit is answered with the reminder that you are holding the outdated version right now and that the corrected file must be delivered again — no more silent “fixed it in the drafts folder”.
• Undelivered-drafts guard. When the AI writes its daily protocol — the “I am wrapping up” signal — the bridge lists by name every versioned draft written in the session that was never delivered at all. Finished work cannot quietly remain stuck in the AI's working storage.
• E-mail format guard. Every access to e-mail content automatically carries the binding pointer to the mail-format tool (subject copy box, body copy box, mandatory content, language rules) — the AI is reminded of the one correct delivery route before it can improvise one.
• Copy-box guard. Every time the AI writes or edits a text working file, the answer carries the reminder that documents reach the user only through the delivery tool — pasting a finished letter into the chat as text or a copy box bypasses formatting, verification and delivery tracking and is a visible rule violation. The one legitimate copy-box artifact remains the e-mail, exactly per the mail-format tool.
• Case anchor. Every tool answer that touches a case carries the case's registered number, client and subject (gate 10) — context invented from another case's memory refutes itself in the same window.
• Model-tier steering. The instructions tell the AI which model class a task needs: before the pleading tools (output format, verification, delivery) it asks you in one sentence to switch the desktop client to the top-tier model, and after delivery it tells you that a cheaper model is sufficient again. When the proposal counters show party-network maintenance (two master-data proposals and a relation or case-link proposal), the bridge appends — once per session — the hint that this fully gated work does not need a top-tier model. You decide; the AI keeps working.

Since the same release, tool execution also runs in an isolated worker thread inside the application — even multi-second AI accesses to large case files never stall the IRONSTICK user interface anymore.

8. The pleading compiler — delivery only against proof

Pleadings and letters are written in dialogue with the desktop AI on the live file — the same working layer and the same gates as IRONSTICK's own chat. What leaves the system is a submission-ready template, never a finished court filing: you review, correct and sign. Two gates stand in front of every hand-over: the deterministic verification below, and — if you switch it on for the active API model in the configuration — the Red/Blue Team: a second model reads the draft as opposing counsel; substantial findings send it back for rework, at most two rounds, every point analysed on the merits and never adopted blindly. If the AI holds the findings unfounded, it re-submits the unchanged file with a written answer to every finding — the reviewer is not run a second time on an unchanged file, and the reviewer report reaches you together with those answers. The hand-over itself runs through IRONSTICK's export dialog, from where the draft goes into the word processor with one click.

A formal pleading cannot leave the system on trust. verify_pleading, a deterministic scanner (no AI involved anywhere), checks the finished draft against your live records and the verified law library across eight claim classes:

• Evidence references — IS stamps and #-numbers, in the annex list AND in the running text: existence, ownership, stamp integrity, and document-bound citation provenance: every cited or attached item must count as read for THIS document — fetched in full, or its scratch file read to 100 %; a reading counts for 2 hours, each delivery of the same document extends it, verifying another document resets the annex readings. Citing from search snippets or from memory fails verification. An annex line may declare a page range (“p. 12–15”); the reading duty stays the whole document.
• Statute citations — the cited article must exist in the verified library text (thousand-dot tolerant, word-boundary exact) AND carry read provenance: the AI must have actually pulled that article from the library in this application run — press articles, web summaries and model memory never ground a norm and fail verification. Cited sub-references (paragraph/point) are existence-checked as well. A source missing from the library does not slip through: the AI must request it, and the request lands in your consent dialog — checked sources are fetched, verified and stored; unchecked ones are declined and every later citation of them carries a visible “user declined” note.
• Verbatim quotes — every quoted passage must be found in full in the case full texts or in the law library (OCR-tolerant). A quote found in no source is CONTRADICTED and blocks delivery. Taking the quotation marks away or lightly rewording the passage does not help: the blocked quote is remembered for the document and stays blocked. A quote struck entirely is allowed — and the delivery tells you expressly which quotations were removed because no source contains them.
• Dosar numbers against your cases and records.
• Amounts with ZERO tolerance — the figure must match the recorded form exactly; “14.500” where the register says “14.500,00” blocks delivery until corrected.
• Party master data — every name used must match the registered spelling letter for letter, diacritics included.
• CNP and IBAN — checksum validation (an invalid check digit is always a hallucination) plus register/records match.
• Named parties — every person or company named in the document must have been read (profile) AND its connections checked (who_is_connected_with); the refusal names the two calls and recommends the clique test (read_cliques) on top.

Every finding is VERIFIED, UNVERIFIED or CONTRADICTED. Delivery of a formal document is refused without a fresh OK attestation for the exact file state — every edit voids the attestation. After five failed verification runs the loop hard-aborts, orders the AI to stop and report, and notifies you directly in the application. And deliveries run exclusively through the application's own working store, so attestation, versioning and re-delivery tracking stay attached to every file — inline delivery and foreign paths are refused.

9. Data note

The tool list reflects the shipped bridge of the described version; tools may be added over time. Names shown are the technical tool names as the AI sees them.

Appendix — Complete technical description of the bridge

Status: 175 member tools · 20 toolsets · MCP protocol revision 2024-11-05. This document describes the bridge exhaustively — architecture, every functional layer, every gate, every limit and every redirection — in prose only.

1. Purpose and positioning

The bridge connects commercial desktop AI applications (Claude Desktop, ChatGPT Desktop, Qwen Desktop, Kimi Desktop) to a running IRONSTICK legal case-management application on the same machine. The desktop AI receives a controlled, self-describing tool surface over the Model Context Protocol (MCP); every call is executed inside the IRONSTICK application against the live database, and every result is post-processed by the bridge before it reaches the model. The design goals are: minimal permanent context load on the model, structural enforcement of working rules that plain instruction text cannot guarantee, protection of unsaved user work, protection of the data against oversized or misdirected requests, and complete absence of readable configuration material in the installed product.

2. Process topology

The bridge consists of two cooperating processes.

The IRONSTICK application hosts an HTTP server bound exclusively to the loopback interface. Its port and a 48-character hexadecimal access token are defined in the application's configuration store; every request must present the token. This server owns the tool registry, executes all tool calls, applies all gates and post-processors, and is the single point of truth for what a connected model may see and do.

In front of each desktop AI stands a small native executable compiled ahead-of-time from Dart. It speaks JSON-RPC over stdio toward the desktop AI (standard MCP transport) and forwards work to the application's HTTP server. Each desktop AI has its own installation directory containing a copy of this executable and a private configuration file holding: the loopback port, the access token, a caller identity string (for example claudedesktop, chatgptdesktop, qwendesktop), the path of the instruction file served at session start, and the path of the delivery script. The caller identity travels with every tool call as an internal argument and drives all per-AI behaviors described later. The front-end also emits a heartbeat to the application roughly every three seconds while a desktop AI is connected; the application surfaces this as a "bridge connected" presence indicator with a fifteen-second time-to-live, so the user always sees whether an external AI is currently attached.

On the MCP initialize handshake the front-end returns its server identity and, embedded in the initialize result, the complete session-start instruction text. Front-ends of version 2.6.6 and later look for a companion file of the configured instruction path whose name carries a core suffix and prefer it; this delivers a condensed core instruction of roughly fifteen and a half thousand characters instead of the full playbook of roughly fifty-six thousand, cutting the permanent instruction load to about a quarter. The full playbook remains available to the model at any time through a dedicated tool (see section 5).

3. Security, licensing and consent

All traffic is loopback-only and token-authenticated. The web-access tools enforce server-side request filtering: only public http and https targets are permitted; localhost, loopback ranges, private networks and link-local addresses are rejected, so a model can never be steered into scanning the machine or the LAN through the bridge.

The bridge and the per-vendor desktop integrations are separately licensed add-on modules. Their availability is encoded as bits in a signed license key; an unlicensed module's front-end and tool surface simply do not come into existence.

For the Claude Desktop connection a consent gate protects first data access per application run: the first tool call after program start raises a warning modal above the current screen. If the user approves, access is free for the remainder of the run; if the user declines, access is blocked for ten minutes and every blocked call returns an explanatory message to the desktop AI asking it to retry later; after the ten minutes the next access raises the warning again. The state is held in memory only and never persisted.

Independently of consent, an instruction access lock guards every desktop connection: no tool — toolset openers, the member-execution tool, everything — executes until the caller has read the instructions and returned the hallucination prohibition (rule 5) word for word through the confirmation tool; only the instruction reader, the confirmation tool and the system-language tool stay open. The confirmation is keyed per desktop AI and lapses sixty minutes after it was given, after two hours without a call, at midnight and on every new connection handshake — after a lapse the caller must re-read and return a randomly chosen rule instead of the one it knows by heart. On the Claude connection every chat is its own caller (told apart through the structured tool events of Claude's local session record, never the conversation text), a chat whose context was compacted is locked at once, without penalty, until it has re-read, and a chat that touches the data folder with its own file tools instead of the connector has that recorded as a rule violation; a refusal names the two calls that open the lock, and the dropdown at the AI's symbol in the application shows the state as a green check or a red cross.

Every data-reading and data-writing function is owner-validated against the license-derived owner identity. Evidence records flagged as secret are excluded from every reading, searching, dumping and stamping function without exception; records flagged as deleted are likewise invisible.

4. Instruction system

The model's guidance arrives in three layers with strictly increasing specificity and strictly decreasing residency.

The core instruction is delivered once, inside the initialize result. It contains the mandate (fact-based legal work at senior-associate standard), the universal rules (dialog language equals the IRONSTICK system language; the jurisdiction of generated documents comes from the case, never from the dialog; date discipline; no quoting from search snippets — every page the AI relies on must be opened and read via open_url, whichever search found it; citation and reference discipline; the retry limit of three attempts per failing tool call; delivery discipline), and the description of the toolset mechanism itself, including the explanation of the home-toolset field described in section 6.

The per-area working rules are not resident: they are handed to the model verbatim and current every time it opens the corresponding toolset, as part of the opening payload.

The complete playbook — core plus all toolset rules plus the appendices (among them the daily-protocol file format) — can be re-read at any moment through the instruction-reading tool; the front-end reads the file live, so instruction changes reach a running session without reconnecting.

Three of these rules are additionally enforced structurally rather than textually, by gates described in sections 3 and 7: the access lock, the date discipline and the statute-source discipline. The reading of the instructions itself is the last rule of the universal block: the way to unlock the connector is stated only after all preceding rules, so a model that reaches it has read them.

5. The tool surface and the toolset layer

A flat list of 175 tools measurably degrades tool selection in current desktop models. The bridge therefore exposes a reduced surface of twenty-eight entries: six core tools (current date and time; current GUI context; system language; case jurisdiction; instruction re-read; instruction confirmation), the delivery tool injected by the front-end, twenty toolset openers, the member-execution tool and the full-inventory tool. Everything else exists only as members inside toolsets.

Opening a toolset is an ordinary tool call without arguments. The answer delivers, in one shot: first, where the toolset has one, a deterministically pre-generated context block computed at the moment of opening (eight toolsets have such producers — the session-start protocol itself; the current scratch file inventory; the ten most recent memory entries as a preview; the first thirty statutes of the legal library; the list of hot cases; today's registered documents and incoming e-mails; today's daily protocol; the current deadline and appointment snapshot); second, the verbatim working rules of the area; third, the complete member-tool definitions with their full parameter schemas; fourth, a fallback line pointing to the full inventory. A failure inside a pre-generation producer never prevents the opening.

Members are executed through the member-execution tool, which takes the exact member name and an argument object. Before execution a lightweight schema validation runs: required fields must be present and non-empty, and integer, number and boolean parameters must parse as such; a violation returns the expected schema instead of executing. An unknown member name returns the closest existing name by edit distance as a suggestion. The instruction layer caps correction attempts at three per failing call, after which the model must stop and report the exact error.

Toolsets are not modal; all openers remain callable at all times, a tool may deliberately be a member of several toolsets, and opening payloads are never diverted to the scratch store (schemas in a file would be useless). Feature gates remove whole groups: when GUI navigation is not enabled by the user, the navigation toolset opener and all its members are absent from every list and every answer. The full-inventory tool lists every member with a one-line purpose and its owning toolset and exists only as an escape hatch; the toolset descriptions are the primary router. In total the twenty toolsets carry 280 member entries over the 175 distinct tools.

The measured context cost of this arrangement: the initial configuration (core instruction plus reduced tool list) is roughly ten thousand tokens; a single toolset opening adds between roughly nine hundred and seven and a half thousand tokens depending on the toolset, before its variable pre-generation content.

6. Tool definition format and its production chain

Every tool definition consists of four parts. The description carries the tool's purpose, its behavioral mandates and its cross-references — and nothing else. The input schema carries every parameter with its own description, including defaults, formats, mutual-exclusivity notes and per-parameter mandates; parameter usage instructions live exclusively here. The output field describes, before any call, exactly what the call returns, including orderings, markers and error forms, so the model can judge suitability without trial calls. The home-toolset field names the toolset the tool primarily belongs to, with a reserved value marking core tools that are always in the top-level list; a member encountered inside a foreign toolset thereby advertises where more tools of its family live, and every toolset opening carries one explanatory line stating that the model is never locked into the opened toolset.

All model-facing text is English without exception. The production chain runs from a single canonical source document through generators into the compiled-in overlay and into the cluster blueprint that documents the toolset topology; the generator aborts hard when any description or output text — at any schema depth — matches a German-language detector, and a drift guard aborts the synchronization when a home-toolset claim points at a toolset that does not actually list the tool as a member. Declared numeric limits in tool schemas are enforced by a shared clamping helper in the executing functions, so a stated maximum is a real maximum.

7. Universal runtime mechanisms

The following mechanisms apply across the entire tool surface and are implemented centrally, not per tool.

Scratch redirection on demand: every tool accepts an additional parameter naming a scratch file; when set, the complete result is written to that file and the model receives only the path and the size — no preview. Large content thereby never flows through the model's token stream in either direction, and the path is directly usable wherever a source path is accepted.

Overflow protection: any result exceeding the connector limit — ten thousand characters, one central constant, doubled to twenty thousand for Claude Desktop and ChatGPT Desktop — is automatically written to a generated scratch file. The model receives only a note stating the total size and line count, the file name, the explicit assurance that nothing is lost, the two continuation commands (ranged reading; pattern search in the file) and the express prohibition of re-requesting the call — no preview, so large content is read where it lives and the model gets used to working from the scratch store. The one exception is the instruction reader, whose package always arrives complete; toolset openers are diverted like every other result. No tool shortens its own result — the connector limit is the only place where size is decided. Results beyond ten megabytes are not diverted but answered with a narrowing instruction naming the applicable filters, since even the scratch store caps file size there. Exempt from diversion are the scratch reading tools themselves (internally capped; diverting them would recurse) and calls that already requested scratch redirection.

Date gate: every tool that writes into IRONSTICK is refused for external callers unless that caller has fetched the current date and time within the last thirty minutes. The refusal names the remedy — fetch the time, then repeat the identical call. The window is keyed per provider, deliberately short so a fresh conversation cannot inherit an old fetch and so midnight rollovers are caught. In-app callers are unaffected. This exists because external models otherwise stamp records with their training-era "today".

Statute gate: web access for statutes and norms is structurally refused until the internal legal library has been consulted; the refusal points to the library procedure. Any statute source that is nevertheless fetched from the web must be reported into the library through the registration tool — the instruction layer classifies omission as a breach of duty, and results touching legal sources carry a marker for auditability.

Navigation hard-block: eight screens are declared protected — the four capture forms (document capture, case-bound document capture, case chronicle capture, client capture), the case creation form, the institution/person assignment form and the text editor. While the user's main window shows any of these, every GUI-navigation and export function is refused at the handler level — the wrapper catches direct calls and member execution equally — with a message naming the protected screen, forbidding navigation, and instructing the model to answer with the data it has and to offer opening only after the user has finished and saved. A model can therefore never destroy unsaved user work by switching screens. The web-page opening tool is explicitly exempt from this wrapper since it shares the name prefix but does not navigate the application.

Navigation offer: results of the roughly forty tools whose output describes a GUI-openable object — a case, a person, an institution, a client, a specific evidence item, an e-mail, calendar entries or deadlines — receive one appended line proposing that the model offer the user to open the object directly in IRONSTICK, naming the exact navigation call. Where the invoking arguments contain the object identifier the proposal is concrete; for search and listing results it references the identifier of a hit. The line explicitly requires user agreement before navigating unless the user's request already was a show/open command. The offer is appended only after the overflow handling, and only when the result is not an error, navigation is enabled, and the navigation hard-block is not active — the block always wins over the proposal.

Caller propagation: the caller identity accompanies every execution and drives per-AI state — the once-per-day work briefing is tracked per desktop AI, peer-review task listings exclude the caller's own tasks, and the call log attributes every line.

Call log: a switchable diagnostic log records one line per tool call across all connected AIs — timestamp, caller, the effective tool name (for member execution the inner member, not the wrapper), the arguments capped at three hundred characters, the result size measured before any overflow diversion, the execution duration and an error flag. The switch lives in the application's configuration store and is re-read with a ten-second cache, so logging can be toggled without restart. It exists for path analysis and toolset optimization and is meant to be switched off afterwards.

Diacritics and script folding: every keyword search, pattern search and comparison across the bridge folds case and diacritics for all eleven system languages, including the Turkish dotted/dotless i (replaced before lowercasing, since it otherwise changes length), Cyrillic variant letters and Latin ligatures; the folding is position-stable where positions are reported.

Result conventions: failures are returned as text beginning with an error prefix and flagged as errors in the MCP result; the model is instructed to correct and retry at most three times, then stop and report. Structured self-describing markers embedded in results (for memory operations, gates and similar) are stable and documented in the respective output fields.

Read-coverage guard: when a model pulls a full-case dump or the whole-case reader's scratch delivery, the bridge records line-exactly which ranges of the dump file were actually read. As long as unread ranges remain, every successful tool answer — searches, pattern matches, everything — carries the exact unread line ranges together with a read percentage; a claimed complete read is therefore impossible. Once the file is fully read, the nagging stops and the next ranged read confirms once that all lines were read, giving the model a provable end of its reading duty. Tracked are the full-case dumps, the head and digest files of the case preparation tool and every document full text that was diverted to the scratch store; partial reads of other redirected results remain legitimate and silent. The coverage state is persisted next to the store and survives application restarts, and a file read to completion is stamped into the preparation ledger — the reading stays valid even after the start-up purge removed the file.

Re-delivery guard: after a successful file delivery whose source lies in the scratch store, a marker file next to the store records the delivered name and time (deliveries passed as inline content are recorded under their delivery name as well). Every later edit, write or normalization of a file recorded there is answered with the reminder that the user is holding the outdated delivered version and that the corrected file must be delivered again under a new version number. The delivery answer itself additionally fetches the current read-coverage state from the application over an internal endpoint that is not a tool, and scolds a delivery made despite unread ranges.

Undelivered-drafts guard: the daily-protocol append — the model's wrap-up signal — lists by name every versioned working file written by the model in the session that was never delivered, with the instruction to deliver the finished artifact now; work that only exists in the scratch store never reaches the user.

E-mail format guard: every answer of the e-mail reading and fetching tools carries the fixed pointer that the binding instruction for formatting and delivering e-mails — subject copy box, body copy box, recipient section, mandatory content, language rules — comes from the mail-format specification tool, to be fetched before building any e-mail and followed to the letter.

Worker-isolate execution: the computational body of the data and analysis tools executes in a dedicated worker isolate inside the application, with its own registry and its own database connections; the application's interface isolate only routes, gates and post-processes. Even multi-second accesses to large case files therefore never stall the application's user interface; if the worker dies, execution falls back seamlessly to the interface isolate and the worker is respawned on the next occasion. Tools that inherently need the interface isolate — navigation, confirmation dialogs, the embedded browser, mail retrieval, and the review-gated writers — are exempt from worker routing by design.

8. Interaction gates

Three tools deliberately answer their first call with a question instead of a result; in all of them the literal answer "unknown" is always valid and never punished.

The delivery gate: the file-delivery tool, called without the formality declaration, delivers nothing and asks whether the delivery is one of the four formal artifact kinds — legal pleading, court e-mail, chronicle entry, daily protocol — or none of them. Answering with "no" delivers immediately — but the claim is content-checked: a deterministic detector inspects the file, and content shaped like a letter or pleading (salutation and closing formulas across six languages, an addressee block, legal markers, an identity block) refuses the informal claim and logs the attempt; such content has no informal path. Answering with a formal kind returns, still without delivering, the binding formatting instruction for exactly that kind embedded in the gate answer; only the repeated call carrying the confirmation flag that the file was verified against this instruction actually delivers. A version-series guard additionally refuses the first delivery under a new file stem while a versioned series with the same case number already exists in the delivery folder — renaming a document to reset its version counter is structurally impossible; a genuinely different document requires a conscious, logged declaration. This gate is implemented inside the front-end executable itself, which fetches the current formatting instruction live from the application. Documents and letters never reach the user as chat text or copy boxes — every writing access to a text working file carries that reminder, and the one legitimate copy-box artifact remains the e-mail per its format tool.

The search gate: the central evidence search, on its first call, searches nothing and asks three things — what kind of item is sought (inbound document, outbound document, evidence with attached document, statement/transcript, chronicle note, or unknown), the scope where a client identifier is present (this case only, all cases of the client, or unknown — with the client's case list included in the question), and the desired answer form. The answer forms are: a clean identifier list (the recommended default; hits are then opened individually through the evidence reader), compact hits with match context, or the full result written to a single scratch file.

The full-case gate: the whole-case reader, on its first call, loads nothing and reports how large the case actually is — the evidence count and the approximate accumulated content volume across titles, descriptions, document full texts and transcripts — then asks the model to decide between targeted search tools and a repeated call with the scratch delivery argument, which writes the complete, OCR-normalized case content into the scratch store and returns only the file handle.

The verification gate: for formal pleadings the delivery tool additionally requires a fresh attestation from the deterministic pleading verifier. That verifier scans the finished scratch file across eight claim classes — evidence references in the annex list and the running text (stamps and numbers, including document-bound citation provenance: every cited or attached item must count as read for this document — fetched in full or its scratch file read to completion; a reading counts for two hours, every delivery of the same document extends its cited items by two hours, and verifying or delivering a different document stem resets the annex readings; an annex line may declare a page range, the reading duty remains the whole document), statute citations against the verified library (an article absent from the verified statute text is a contradicted finding; the citation additionally requires read provenance — every library read is recorded per application run with the article numbers actually returned, and a cited article without such a read record is a contradicted finding, so press articles, web summaries and model memory can never ground a norm; cited sub-references such as paragraph and point are existence-checked in the article's text region; a source absent from the library blocks until integrated or declined), verbatim quotes — each must be found in full in the case full texts or the legal library; a quote found in no source is contradicted and blocks delivery, a quote whose marks were merely removed or whose wording was lightly changed stays blocked, and quotes struck entirely are reported to the user at delivery —, dosar numbers, amounts under a zero-tolerance rule (the exact recorded form), party master data letter for letter including diacritics, personal/bank identifiers through the checksum validators, and named parties — every person or company from the entity register that is named in the document must have been read (profile) and connection-checked for this document, with the refusal naming both calls and recommending the clique test. Findings are graded verified, unverified or contradicted; any contradicted finding or unresolved missing statute yields a blocking verdict. The attestation binds to the exact file state — any edit voids it — and after five failed verification runs the loop hard-aborts, instructs the model to stop and report, and notifies the user directly in the application.

The consent gate for statute sources: a statute source reported by the model is no longer integrated silently. Requests collect in a single consent dialog in the application — source, jurisdiction, requesting AI — where checked entries are fetched, verified and stored (with an immediate worker kick) and unchecked entries are declined; a declined source turns later citations of it into visible unverified-by-user-decision notes instead of silent blocks. The data monitor thereafter carries statutes only for the periodic review cycle.

The store-only delivery rule: the delivery tool accepts exclusively a source path inside the application's working store; inline content and paths outside the store are refused for every file type. This keeps the verification attestation, re-delivery tracking, versioning and read coverage attached to every delivered artifact without exception.

9. Session start and framing

The session-start toolset's opening runs the entire start protocol in one shot and writes it to a fixed, named scratch file; the direct answer returns only the date anchor, the system language and the current GUI context, and the model reads the remainder — due memory entries, the daily briefing, deadlines, appointments, open peer tasks, and the index of the last ten daily protocols — with a single scratch read. The members of this toolset re-run single pieces on demand.

The date-and-time tool answers with one line (date, time, timezone, weekday, NTP-synchronized where possible, otherwise system clock) and carries the standing mandate that every dialog turn begins with the current date and that dates are never guessed. The GUI-context tool reports which screen of the application's main window is open, with breadcrumb and the open client and case. The system-language tool returns the language identifier governing dialog and cross-case lists; the jurisdiction tool returns, per case, the jurisdiction that governs generated documents and terminology, is mandatory before any document work, and instructs asking the user when unset. The morning-briefing tool returns today's structured briefing with identifiers and markers so the model can act on each item; the work-briefing tool tracks per desktop AI whether that AI was already briefed today, returning the recent daily protocols only on the first contact of the day.

10. The scratch store

The scratch store is the model's working folder for everything large. It offers writing with append capability for chunked assembly; line-numbered ranged reading whose numbers map directly to the line-based editors; exact text replacement with uniqueness requirement, a whitespace- and typographic-quote-tolerant retry that still requires uniqueness, and an instructed fallback to locate-and-copy on any other mismatch; insertion by line number or after a marker; line-range deletion; atomic line-range replacement as the safe restructuring operation; case- and diacritics-insensitive pattern search across one or all files with a fifty-hit cap and optional context lines; a markdown outline that maps headings to line ranges without reading the file; a directory listing; copying; a line diff between two files that hides common lines; delivery-oriented normalization that flattens structural markdown to the pleading conventions, protects references, pads short evidence references to seven digits and normalizes line endings; whitespace equalization; line-ending and invisible-character cleanup; destructive equalized projections (a lowercase comparison skeleton, or diacritics folding only) always into a separate target file; word, letter and line counters; and deletion.

A lightweight state register remembers key-value notes for the running session — above all which file is the current main draft — with get, set and clear semantics, surviving application restarts.

Lifecycle: the store is long-lived and survives restarts; the model's own notes, the state register, the file metadata and the read-coverage bookkeeping persist, while tool dumps from earlier days are purged at every start and files untouched for one hundred eighty days are purged. Every access through any scratch tool — including a plain read — resets that file's deletion clock; a mere appearance in the directory listing does not. The instruction layer obliges the model to delete its task files when a task ends and to move durable insights into the memory system instead.

11. The memory system

The persistent AI memory is a cross-chat notebook shared by all connected AIs and the in-app assistant. An entry holds at most one thousand characters — the toolset and tool descriptions demand compression to the absolute essentials and splitting of larger material — and is linked at minimum to a client or a case (with a case link the client is derived and corrected automatically) and optionally to an evidence item, an e-mail, an entity or an institution, all validated. Entries must be written in the IRONSTICK system language regardless of dialog language, and the model is forbidden to use its own private memory files for case knowledge, since those reach neither the peer AI nor the user. An optional due date makes an entry deadline-like: due and overdue entries surface first in the session-start protocol and in the application's deadline views.

Search is filterable by any of the linked identifiers and by due date (everything, exactly today, or a window of ten days around a given date), returns newest first with a default of twenty and a maximum of fifty hits, and marks user-authored notebook entries as strictly read-only for the AI. Updating replaces text and/or moves, sets or clears the due date; everything not supplied stays unchanged. An update whose text exceeds the limit is rejected with a capacity statement naming the submitted length, the limit, the entry's current occupancy and the free remainder; every successful text update likewise reports occupancy and remainder; in both cases, once fewer than three hundred characters remain free, the answer appends the standing recommendation to either rework the whole entry or create an additional entry and leave a cross-reference in the old one. Deletion is irreversible and refuses user notebook entries and task entries. Housekeeping is built for long-running proceedings: entries linked to a case are exempt from the one-year purge for as long as that case is active — they fall only when the case is set inactive or archived (which purges its entries immediately) or when the client is deleted; the one-year purge applies to case-less entries only. In addition, every entry returned by a memory search and every update of an entry refreshes its lifetime, and the purge measures age against the most recent of creation and last access — an entry that is actually used never expires; only dead material ages out. User notebook entries never expire automatically.

Master data, persons, relations and documents do not belong in the memory: the descriptions route them to the proposal tools and to document capture.

12. Deadlines, appointments and the calendar

The deadline tools deliver the active deadlines either compactly (title, due date, days remaining, case, with secret-flagged entries excluded) or with per-entry descriptions and explicit overdue and urgent markings (urgent meaning ten days or less), and a recital form ordered by urgency with period filters (all grouped by criticality, critical only, due soon, today, this week, next week, or a specific date). The appointment tool recites a day or period ordered court dates first — portal-imported court dates, then calendar court dates, then remaining calendar entries. The calendar reader lists entries globally or per case with optional date range.

The calendar capture tool never writes: it opens the application's calendar form prefilled with title, date, times, description and optional case link, and the user completes and saves. Its description imposes a mandatory duplicate check before every call: read the same day's calendar first, compare by date only while ignoring times, and on any similar entry show it to the user and ask whether it is the same event, calling the tool only after the user confirms a new entry.

13. The daily journal

The journal system writes and reads the cross-case daily protocol. Appending targets a day (default today, with the date fetched through the time tool), always appends to an existing day with a separator and never overwrites, links affected cases through a case list, and expects the content as clean markdown in the protocol style defined in the instruction appendix. A note tool adds a single event line into today's protocol with an optional case reference. The format tool returns the binding protocol file format. Reading works by date, range or newest-first with full-text option and case scoping; searching is a diacritics-insensitive keyword search across titles and full texts with date, title and context excerpt per hit. Both listing forms default to ten and cap at thirty entries. The toolset opening already delivers today's protocol in full with a note how many further protocols exist in the last two weeks.

14. Case access

Case resolution works by case number, by involved party name (diacritics-tolerant, covering opponent, claimant, title and client — mandatory whenever the user names a party without a number, since many cases carry no number at all), and through the client's case list. Related proceedings come from the case hierarchy as parent, child and same-group entries.

The quick overview tool returns, in one call, every field of the case tab, every field of the client tab, an optional linked portal docket, and the last fifteen evidence identifiers with entry dates — intended as orientation before any full-text access. The chronicle reader returns a case's chronicle newest-first, compactly and without full texts, with date filters and a limit of up to fifty entries, and is the designated quick answer for "what happened last" — it counts for nothing toward case preparation.

Case preparation is a tool and a gate. The preparation tool delivers, in one call, the head (profile and jurisdiction) and the digest of every document — identifier, date, type, title, the capture-time summary, cross-references and full-text size — which is the chronicle; a second listing of the same rows was dropped as pure token waste. The answer always begins with a note naming where head and digest are (inline when the whole answer stays under the connector limit, otherwise as two scratch files that must be read to completion) and the five newest documents to read in full. The preparation gate then refuses, for external callers, two tiers of case output: a note or entry on a case (journal, daily note, chronicle entry, case note) until profile, jurisdiction, digest and the five newest chronicle entries (notes without a PDF or transcript; images allowed) are read in full — so a running series of chronicle entries respects the last ones, without forcing heavy documents to be read for a mere note; a judgement on the case (pleading verification, hand-over, export) additionally until every cited or attached document is read in full. Readings are booked per desktop AI in a persisted ledger, valid for three days or until the next inbound document of the case; outgoing documents and evidence records never invalidate a reading. The same ledger feeds the dropdown at the AI's symbol. A third, lower tier guards case content itself: every case-content tool — chronicle, timeline, keyword, passage and period searches, full texts, contradictions, statements, obligations, deadlines, calendar, correspondence, usage, filed exhibits, letter chains, annex lists, stamps, media, institutions, tags, assessment and instruction notes — is refused for a case whose digest the caller has not read, the refusal naming the preparation tool; the third refused attempt on the same case is booked as a rule violation. The preparation counters reset with every instruction reading and session start.

Complete case reading is gate-protected as described in section 8. The scratch dump is the fastest complete path: it assembles the whole case text inside the application, untrimmed, normalizes OCR anomalies (repeated spaces, line-ending mixtures, non-breaking spaces, soft hyphens, zero-width characters), writes it directly into the scratch store and returns only the handle with statistics; very large cases split into numbered part files. Scope filters restrict the dump to inbound, outbound or both directions, and an evidence-identifier list dumps exactly those records — the designated way to read one very large document completely, with the case derived from the evidence.

The evidence reader is the mandatory basis for every substantive statement: it loads a record with its extracted document full text (complete and untruncated; above the connector limit it arrives as a whole in the scratch store) and, where present, the chat or transcript full text (covering messenger chats and phone, hearing, interrogation and court transcripts), plus the qualified summary, description and metadata, which are declared no substitute for the full text. If neither full-text section appears, no extracted text exists and the model must not make substantive claims about the record. A comma list of up to twelve identifiers reads several records in one call. A media inventory tool reports the existence, type, date and size of image, audio and video attachments of a record or case, explicitly stating that media content is not readable as text and exists so a record with only media is not misclassified as empty.

Tags are surfaced as free-form user post-its on evidence records — the text is the information, the color has no fixed meaning, and a tagged record is declared a strong relevance marker. Three modes deliver a global overview with counts and referenced records, all tags of a case, or a text search within tag texts, with a scope filter separating personal from case-bound tags. Matter groups list a client's entire case landscape as groups with nested cases including tree parentage. The stored case assessment is retrievable per case.

15. Search inside the file

The central evidence search scores across all evidence fields, the extracted document full texts and the transcript contents, with multi-word queries combined conjunctively, diacritics independence and a phrase boost; results are ordered by relevance without exposing score numbers, each hit labels which field triggered it, the default is fifteen and the maximum thirty hits, and the answer form follows the gate choice of section 8. The passage search splits documents and transcripts into paragraph and sentence windows and returns the best-matching passages with their reference — locating where in a text something stands, not merely which record — with OCR-tolerant matching that bridges capture errors, a phrase bonus, and scoping to exactly one case or to all cases of exactly one client (the designated instrument for "did X ever, anywhere" questions; never across clients), defaulting to eight and capping at twenty passages. A date-range tool lists evidence between two dates. The dedicated correspondence-from-party finder is mandatory when the user asks for documents from or to a specific party: it matches the party diacritics-tolerantly against the involvement records, filters by direction (to me, from me, or both), excludes chats and transcripts, hides self-made screenshots by default while stating their count, and orders newest first — expressly distinguished from the keyword search, which would also return records merely mentioning the party.

16. Deterministic analysis tools

These tools compute from the records without any AI involvement. The timeline returns all items of a case ordered by event date descending with reference, timestamp, record type and title, defaulting to three hundred and capping at five hundred items. The contradiction collector deliberately does not judge: it gathers up to one hundred twenty candidate items (default sixty), optionally filtered to one entity, with reference, date, participants and short content, and leaves the judging and the follow-up full-text reads to the model. The who-said-what tool finds every item in which a person occurs — as participant, in title or text, or inside transcript wording — diacritics-independently, marking the source of each hit, with a default of forty and cap of one hundred. The participant-network tool counts which persons and entities co-occur in the same items, globally or per case, optionally focused on one entity. The obligations tool lists open deadline-flagged items by due date with day counts, descriptions, references and overdue/urgent marking.

Five further deterministic tools serve the characterisation of individual judges and prosecutors; only incoming documents from a court or a prosecutor's office count as decisions. The decision lister returns every decision in which one person sat as judge or acted as prosecutor, across all cases, counting only a name in the header (composition of the court) or in the signature block — a name in the running text does not count, and court clerks are never listed. The structure reader dissects one decision into court, section, case number, kind, number and date, session, panel, the sentence naming parties and object, the operative part verbatim, outcome keywords, remedy, pronouncement, statute citations with their library status and the size of the reasoning, each with its character position, reporting what is absent as not found. The submission collector writes every submission filed in the case up to the date of the decision into two scratch files — the client's outgoing and the opposing side's incoming documents — restricted to documents addressed to a court or a prosecutor's office, each with its main document only (covering e-mail and annexes cut off), listing what cannot be classified as unassigned; its files carry the reading duty. The ruling comparison measures which share of the court's own reasoning matches, as text, the client's submissions, the opposing side's, both, statute text of the library, or nothing (the court's own wording), measures the recital of the parties' positions separately, and lists the matching passages with their match rate from seventy percent upwards, highest first, in the original wording with character positions. The document comparison holds any two documents against each other across clients and cases, classifies matching passages as statute text, common quoted source or shared only by these two, and opens its answer with the notice that it gives a first impression only and that both documents must be read completely before anything is stated about a connection.

The submission-tracking family is deterministic against the stored pleadings: the usage tool answers, for one evidence item, which annexes it physically contains and in which pleadings it was itself submitted (with date and docket, across cases), or, for a case, the gap report of items never submitted; the submitted-evidence lister returns per stored pleading the attached identifiers plus the deduplicated total set and is mandatory before composing a new pleading's annex list, with the documented caveat that only structurally attached annexes are covered. The registry-number chain finds, from a letter number or from all numbers occurring in one document, every document sharing that number in chronological order — the documented course of an administrative procedure. The annex lister resolves one document's physically contained annexes including the deterministic filing stamp per annex; the stamp tool resolves any evidence identifier to its deterministic filing stamp (several stored files yield several stamps; a record without a stored file yields an explicit empty marker). Both stamp-bearing tools prohibit inventing stamps — they must always be fetched.

17. OCR healing

A four-step escalation path repairs ruined stored full texts and is explicitly barred from use as a convenient reading substitute. The rescan request asks the application to re-OCR the stored original PDF; the user selects the pages in IRONSTICK, and the model is instructed to inform the user in one sentence and wait. The status tool is to be called once when the user says the pages were chosen — polling loops are forbidden — and, when ready, returns the work order together with two scratch files holding the fresh scan and the current database text. The comparison-and-healing rule permits only mechanical OCR corrections, never rephrasing, with numbers, names and amounts kept exact. Where a spot is unreadable in BOTH sources, the model may ask the user for a sight check before submitting — at most three points per document, with the record opened at the exact place and the spot named precisely ("page 7, second paragraph — the amount?"); with navigation disabled the record and page are named in chat instead. The submission tool hands the healed scratch file to the application, which shows it to the user in a modal; only the user's save replaces the database text, and nothing is stored automatically. The last escalation, the PDF hand-over request, opens the record and has the model ask the user to drag the original PDF into the chat personally — the bridge deliberately provides no path assistance, refuses hard when no rescan preceded, and refuses PDFs over ten megabytes or over ninety pages; the model then reads the PDF visually, builds the healed version in the scratch store and submits it through the same review gate. On a size or page refusal the flow does not end: the transcription fallback still opens the record, and the model asks the user to open the PDF via the paperclip and type off the decisive spots verbatim ("page X, near the top, it should say … — please type it exactly") — at most three spots, taken over verbatim into the healed version; any remaining gap is disclosed openly. The lawyer thereby acts as a visual precision instrument for exactly the fraction of a scan the machine cannot resolve, instead of processing the document manually.

18. Persons, institutions, clients and data proposals

Resolution tools find clients, persons and institutions by name fragment, diacritics-tolerantly; a keyword finder searches names, notes and analysis fields when only a fragment is known. A deterministic list check matches a document that contains a list of names against all persons and companies on record, addressed by evidence identifier or by case — then the newest entry of the case is scanned and named in the answer. On the Claude and ChatGPT connections the party check accepts the next parties in advance and searches them in the background while the current one is worked through; results are kept thirty minutes and the order of the gate stays unchanged. Network tools list everyone connected with one party by explicit relationships and shared cases, the cliques of the whole party network by deterministic community detection (exactly the Universe view of the persons screen, with a suspicious flag for unusually dense groups and an optional separation of persons and institutions into layers), and the most connected parties; every party-related answer starts with the block of cases the party is linked to. The profile reader returns every master-data and analysis field complete and untruncated. Profile readers return the entity profile with analysis and relations, all relations of a person in both directions across persons and institutions, the institution profile, and the institutions formally linked to a case. The time-tracking reader reports passively measured working time (each page view lasting until the next, capped at thirty minutes, the last one counted as one minute) as an overview of totals and top cases, clients and days, or as a per-day breakdown of one case, over a date range or a trailing-days window defaulting to seven.

Writing into master data is impossible directly. Two proposal tools place findings into the application's data-consistency monitor as review items: the master-data proposal (only after the user confirmed in chat that the finding should be filed) targets an existing entity or institution — resolved first by name — or describes a new record by name and fields, with an allowed field list in which corporate and personal identification numbers share one field, only substantiated fields permitted, and optional evidence references; the relation proposal describes a relation between two resolved persons or between a person and an institution, with exactly one counterpart, a mandatory category, an optional substantiation and optional case, client and evidence references. A proposal may also rename a record (field Name), set its kind (field PersonKind: natural or juristic), change the category of an existing relation, propose a deletion (of a record, a tag or a done deadline) with a reason in the system language that is mandatory, or propose two records as duplicates; a new record is accepted only after the kind was decided in the dialog, and a proposal touching a person's description or contact details is refused unless the caller read that profile within the last thirty minutes. In both flows the record changes only when the user accepts the proposal in the monitor. A new-record proposal is first answered with the list of similar existing records — loosely matched, nothing stored — and the caller must either file against one of them or confirm explicitly, by parameter, that the party is genuinely new; a strict match is redirected to the existing record. Every stored new party returns a mandatory follow-up ordering the caller to research and file the party's connections, web research included. A third proposal tool assigns a party to a case: exactly one entity or institution, a mandatory reason and optional evidence references become a case-link review item in the same monitor; acceptance writes the participant link that the clique and connection views build on, while an existing link, a pending duplicate or an earlier rejection is reported instead of re-proposed. The application also counts proposals per caller: after two stored master-data proposals and one relation or case-link proposal it treats the session as party-network maintenance, appends once a hint that this fully gated work needs no top-tier model, and — in the in-app chat — keeps the run on the medium model tier. Independent background processes feed the same monitor: a data extractor deduplicated at the source and a periodic normalization scan that proposes merges and reclassifications along the three-category model (natural person; juristic person as any corporate body that is not a single human, with a commercial-register entry outranking state ownership; institution as state bodies without register entry) — never merging automatically.

19. The legal library

The library holds full statute texts as markdown files with an internal registration number per statute. The listing tool pages through the inventory (identifier, jurisdiction, title, kind, file name, last-check date; default fifty, maximum five hundred) and is read-only. The search tool is mandatory before any internet search for a norm: it matches either by designation against title and description or by quoted passage with fuzzy tolerance (roughly sixty percent of the words suffice and word endings are tolerated), requires the jurisdiction taken from the case, ranks title matches far above content matches (a title match counts nine tenths, each content hit one tenth, at most three snippets per file), and returns per hit the registration number, the file name, short snippets with their exact character positions and a ready-made verbatim-excerpt call whose range is already enlarged — by at least five hundred characters beyond the snippet — so the model fetches the authoritative wording itself instead of trusting the snippet. The excerpt tool returns the verbatim content of one statute between two character positions, addressed by registration number, clamped to the file, prefixed by a note that the range can be adjusted and that the whole statute is loadable, with oversized results auto-diverted to the scratch store; digit matching inside statute searches uses boundary rules that tolerate the thousands-dot notation of official portals. Whole statutes are loadable by file name or by registration number, with large files auto-diverted. The registration tool is the mandatory report channel for any statute found on the open web: only the link, jurisdiction and optional title and sentence are submitted; a background process fetches, converts, stores and announces the source in the data monitor, and the model itself never converts anything. A library review cycle tracks the last-check date of every source. A statute uploaded by the user as a file without an online source carries a currency warning in every answer, because its being in force cannot be verified. Rejecting a statute in the data monitor requires a confirmation that states the consequence: the law leaves the library, and rejecting an update removes the entire law, on the office server too.

A re-check tool verifies one statute against its source on demand and reports unchanged, updated or duplicate; a fresher fetch takes the entry over, and on the office server the last checker wins regardless of who registered the statute first. Whole statutes above the connector limit land in the scratch store and register nothing as read; provenance comes from the article tool.

20. Validators and registries

Deterministic verification tools cover: IBAN (format, country-specific length, checksum); national personal, insurance and tax numbers across nine schemes in six countries via check digits, with a targeted mode per scheme and an automatic mode that tests all schemes and reports the valid ones; European VAT identifiers (offline country-format check first, then the official union live service, returning released company data where the member state provides it); EORI numbers against the union's live validation service; legal-entity identifiers (checksum first, then the global register for status and name); and commercial-register numbers through the European business-register portal rendered in a real browser engine, with the model instructed to read the returned page and confirm the finding. Every validator returns a concrete, reasoned result — valid with details, invalid with the failing aspect, not found, or service unreachable including the status — never a bare yes or no, so a genuinely wrong number is always distinguishable from an outage. The instruction layer makes running the matching validator mandatory before any such number enters a produced or reviewed document. The same toolset carries the coarse user-location tool (country, city and public address from the latest login snapshot, explicitly not a jurisdiction source) and a best-effort weather tool.

21. Web access

Two tools reach the open internet, both framed as supplements to the desktop AI's own web capabilities, with the explicit instruction to use them directly when the AI has no own web access, and the prohibition of using them for case-related data. The search tool queries through a human-like web interface with a choice of engines and returns titled, linked hits meant to be followed with the page opener. The page opener fetches exactly one public URL with a staged pipeline that the description enumerates in full so the model never gives up prematurely: a human-like HTTP request with real browser headers, redirect handling and compression; automatic detection of anti-bot challenges with escalation into a real embedded browser engine; detection of JavaScript shell pages with rendering until content appears; page-exact PDF conversion using the text layer per page and OCR only for scanned pages, so mixed documents work; and conversion of office and text formats into readable text. Output is markdown, complete: the main content is extracted (navigation, advertising and cookie banners removed), pages without an article body keep their footer because address and contact data stand there, and where the extraction would leave next to nothing the whole page is delivered instead. A call answers within forty-five seconds; a large or scanned document is processed further in the background and delivered at once on the next call with the same address. Statute portals are refused until the library was searched, per the statute gate.

22. GUI navigation and exports

All navigation is opt-in through a user toggle; without it the entire group does not exist. The navigation tools open, in the application's main window: a case (optionally on its chronicle or assessment tab), a client's case list, a person, an institution (both highlighted with detail opened), an evidence entry (correct chronicle page, highlighted), the dossier preparation (with a full-automatic variant reserved for the user's explicit wish for a complete PDF), the daily protocol (optionally a specific day's detail), the e-mail monitor (optionally a specific mail's detail), the global search with a fired query (reserved for the explicit wish; chat answers use the internal search instead), the backup area with an immediate backup start, and any named screen from the canonical screen list. Export dialogs cover the client list, the deadline list, a client's case overview, the case dossier in two document types and the map, plus the client AI-package build. All navigation tools are subject to the hard block and are the targets of the navigation offers of section 7.

23. Writing, formats and delivery

The writing toolset binds document production to fetched specifications. The output-format tool returns the binding generation instruction for the requested artifact kind — for pleadings differentiated into legal pleading versus simple letter, each in represented and self-represented form, with the case's jurisdiction, language and date resolved directly into the instruction and placeholders that the model fills from connector data; the mail-dispatch format tool returns the binding specification for court mailings with sequential package delivery. Both must be followed to the letter. The editor hand-over pushes a markdown pleading directly into the IRONSTICK word processor with the text loaded but nothing stored — the user reviews and saves — and is available on the Claude connection. The chronicle capture tool opens the prefilled chronicle form in the correct case, saving nothing itself.

Delivery of files to the user runs exclusively through the delivery tool, which the front-end executes itself: the file lands in the dedicated delivery folder under the user's downloads directory, the folder opens with the file highlighted, and a link is printed. The folder is delivery-only — nothing in it is ever read, edited or deleted by the model. Content arrives either inline or, preferred and mandatory for large or already-written files, by source path, which the front-end reads directly from disk so nothing is retyped through the model, including binary formats. The model versions file names itself, one new number per delivery, with same-name delivery overwriting; the result reports the existing versions of the name stem and the highest one, warning when the delivered number is not the highest. Delivery is once per task, at the end, never for intermediate states, and passes the formality gate of section 8 first.

24. Peer review between AIs

The hand-over tool passes a produced piece to the other desktop AI: the content goes into a short-term large store, a task record references it, the instruction (capped at a thousand characters) states what the peer shall do, and the model then asks the user to trigger the peer in the other application. The inbox tool lists open tasks addressed to the caller — its own never appear — with identifier, assignment and full content, optionally filtered by client or case. The reply tool closes a task (deleting its short-term content) and simultaneously sends the assessment back as a new task to the original sender; the completion tool closes without returning. Scratch read and write are members of this toolset for handling the exchanged content.

25. AI instruction files

Per case the user can store instruction files that the model must consult. The lister shows a case's instructions with identifier, file name, size, upload date and excerpt, without full texts; the global inventory lists every instruction across all clients and cases; the single reader returns one instruction untrimmed by its numeric identifier with an option to route the raw content into the scratch store byte-exact for pass-through; the bulk reader returns all of a case's instructions in one call with the same scratch option. Both listing outputs auto-divert when oversized. The update tool proposes a changed version through exactly one of three ways — an append fragment (the preferred way for additions, with the application assembling the result itself and the model forbidden to reproduce the existing content), a source path to a complete new version on disk, or the complete new content inline — and the application shows the change to the user as a diff; only explicit approval adopts it, the outcome (approved, declined or pending) is returned, and a pending state forbids re-sending. The package export builds a client's complete instruction-and-skill bundle and opens the export dialog.

26. Companion integrations outside the tool surface

One client-side companion complements the bridge without being part of the MCP surface: an installable skill plugin for each desktop AI (five skills mirroring the toolset-and-run-tool working model, generated and versioned by the application's configurator). The bridge front-end configuration for each AI is written by the corresponding configurator buttons, which always write the caller identity and instruction path to protect against configuration sharing between AIs.

27. Failure and refusal semantics — summary

Every refusal in the system is instructive rather than bare: schema violations return the expected schema; unknown names return the nearest match; the date gate names the exact remedy; the statute gate names the library procedure; the navigation block names the protected screen and the deferred alternative; the consent block names the retry window; oversize answers name the file and the two continuation commands or the narrowing filters; validator failures name the failing aspect and distinguish outages; capacity rejections in the memory name occupancy and remainder and, near the limit, the restructuring options; the delivery and search gates name their answer options including the universal unknown escape; the access lock names the two calls that open it; the preparation gate names the unread parts with identifiers and percentages; the pleading verifier names, per expired or reset reading, the exact call that restores it. The model-facing contract is that after at most three corrected attempts on any failing call the model stops and reports the exact error to the user.