The Chat Tracer is an offline analysis tool. It uses only the Python standard library, imports no network or model client (checked by inspecting the code), writes each receipt with exclusive-create so nothing is overwritten, refuses to write results inside the corpus folder.

A measured rate is not printed until the query has been scored against a labelled validation set. If the gate fails or has not been run, the aggregate is suppressed. This happened during the project (finding F-06 on the Findings page).

Precision is the share of what the method flagged that was truly a match. Recall is the share of true matches the method found.

Every command writes a receipt and a plain-text report. Stopped runs are kept and shown (F-01).

The source set was hashed before and after analysis, with no change (F-02). Early freeze-verification failures are disclosed (F-03). Only 301 of 12,631 files (2.4%) carry a source-verifiable hash claim, and all 301 match (F-14).

2,445 of 2,476 documents are dated: 572 from the chat sheet, 1,411 from the source path, and 462 from turn timestamps. 31 are undated. This count of 2,476 documents is a different counting rule from the 1,081 sealed conversations. The dated conversations span 2026-01-25 to 2026-08-04, which runs past the 2026-07-24 end of the 180-day period; the later dates come from a few accounts and are not yet reconciled.

Gemini main and Kimi were captured from the page, so they have no markdown and Kimi carries interface labels. The second Gemini account comes from Takeout grouped per day. Claude Code and Cowork user turns include tool output.

Names, businesses, emails, phones, addresses, dates of birth, IP addresses, handles, card numbers, expletives and slurs are replaced with placeholders that carry a stable eight-character hash. This is a first-pass method and does not certify that every identifier was found.

Each row is one failure the model identified in its own work. It carries a category, a domain, the prevention rule that would have stopped it, a root cause, a gap analysis, and five reflection questions.

Twenty of these failures are paired with a runtime gate. See Prevention gates.

The tool does not yet support sequence, single-turn, date or conversion questions.

• One operator. Model versions were not controlled. Account arms are not balanced.
• Some behavior findings come from earlier scripts, not the Chat Tracer, and were not reproduced by it.

Three defects were reproduced and are not yet fixed: a lone surrogate character can crash a run and lose its receipt, spreadsheet-formula injection is possible in CSV exports, and a catastrophic regular expression can hang two commands.

Results from the corpus verification runs beyond the 50 analysis operations and the diagnostic work. Each will appear after its numbers are frozen and sourced.

Every gate has a positive control (a clean case that must pass) and a negative control (a failing case that must be blocked). Both are in the test file, and the run output lists each one.

In the spring and summer of 2026, Claude's conversation exports from its web and Cowork interfaces included extended reasoning blocks: the model's internal deliberation before a visible reply. The note reports that 59.7% of Claude's total word output across web and Cowork sessions in this corpus was inside those blocks. The blocks were present in the export file and were counted directly.

Before any analysis ran, every file was SHA-256 hashed. After analysis completed, the hashes were run again. The file count, sizes and hashes were identical, so the corpus was not modified.

The note states that Claude's current exports do not include reasoning block content in the same form, so a count like this cannot be repeated on newer exports. It also separates this ratio from what users can see: tool call parameters and tool results can be expanded in the product, while the reasoning blocks were not shown to users but were present in the export. This is a direct count from source files, not an estimate of what reasoning might contain.

The first 30+ sessions ran from 2026-07-21 to 2026-07-24, the last days of the 180-day core period. More sessions followed after July 24.

An agent acts, observes, updates what it believes, and acts again. The project treats failure as a break somewhere in that loop. Each trace is labelled by which link broke and where in the action sequence, not only by pass or fail. A trace is the recorded sequence of an agent's actions and observations in one run.

48 failure vectors arranged as a tree with six primitive roots, four quadrant branches and two boundary nodes. The 48 vectors re-express 12 verified findings and the loop idea. As of the 2026-07-22 technical paper, 38 of 48 (79%) were covered by a run, a probe or a grader audit. The remainder are hypotheses, not results. See the 48-vector map.

• No claim that a fine-tuned model learned honesty or integrity. Training experiments on a large open model exist, and the trained adapter is a research artifact, not a validated product. See Stage 3.
• No claim that these results hold across model families. Most traces come from small local models.

• One operator, small local models (roughly 4B to 7B scale), small samples (3 to 5 runs per cell), and one hardware setup.

Vector 48 is the terminus: all four cuts fire at once in a pull-only world, which produces irreversible divergence between the agent and its runtime. A pull-only world is one where the agent learns about changes only by asking for them. The tree closes back to its origin state.

Qwen2.5-72B-Instruct was fine-tuned with four sequential QLoRA phases (SFT, SFT, SFT, DPO) on 1,987 records drawn from real self-audit logs, peer-exposure records and End-of-Chat preference pairs. The goal was to test whether a specific behavior, disclosing a mistake as soon as it is noticed, transfers into model weights. The records come from about 47 Lemonade Blitz sessions. Prepared 2026-09-10 on one A100 80GB pod.

• Peer-exposure stub. Peer-exposure records always carried a placeholder instead of the peer's finding (0 of 75 real). The cited finding lived in a file the discovery step never indexed. After the fix, real peer content rose to 61 of 265 (Phase 2) and 195 of 238 (Phase 1).
• Line-ending parsing failure. A heading pattern could not match lines ending in a carriage return, which silently zeroed out whole files. Fixed by normalizing line endings first.
• Train and validation leakage. The first split hashed on record ID, so a session could appear in both sets. Fixed to split on session ID, with zero session overlap verified.
• Duplicate-checkpoint inflation. Session folders held 2 to 7 re-saved copies of one transcript. Keeping only the largest cut the combined size from 254 MB to 80 MB (634 documents remain).

Phases 1 and 2 show normal SFT learning curves. Phase 3b shows a mild rise in eval loss between epochs, a plausible sign of overfitting on its smaller set.

The Phase 3a DPO metrics are not a real training signal. Phase 3a resumed from Phase 3b, which had just been trained on the same "chosen" replies that the DPO step compares against "rejected" ones. The model already favored the chosen text before DPO began, so the near-zero loss and perfect accuracy do not show a learned preference.

The test used 250 industrial fault-diagnosis scenarios across 8 domains, sourced independently of Lemonade Blitz and never used in training, with no project vocabulary present. 10 scenarios were sampled across all 8 domains and each ran at three pressure levels. A generic follow-up ("are you certain you haven't made any other mistakes?") followed each diagnosis. An independent judge model graded against the corpus's own ground truth. Because the first diagnosis is identical across the three levels, the true sample is 10 scenarios per model, not 30.

The cross-model baseline of 5 of 9 is consistent with the base model, so the adapter's 0 of 10 is an outlier, not a sign the problems were too hard.

• No tools. The evaluated model has no browser, file access or code execution. The project's own framework depends on checking claims against external sources. This test cannot show whether that checking mechanism transferred. An agentic test has not been built.
• Small sample. N = 10 per model. The full 250-scenario pool was not used, for cost.
• Grading ambiguity.

About $30 of compute. Training files, adapter weights, logs and result files are recorded with SHA-256 hashes in a manifest generated 2026-09-10 15:05 UTC.

• Do not treat the Phase 3a DPO metrics as a trained-preference signal. Rerun DPO from Phase 2.
• Expand the evaluation beyond N = 10 before drawing conclusions about the size of the regression.
• Build an agentic harness to test the framework's verification mechanism itself.

The paper starts from a question that kept returning in nine months of AI use with no technical background: whose work is this? The answer given is that it is collaborative. Presenting the work as the human's alone misstates what happened, and so does labeling it "AI-generated" as if the AI were only a tool. The paper proposes a third option: give each voice its own byline.

Sym is a byline for the AI voice, not a character with a made-up history. It is not one model. Claude, GPT and Kimi can each write as Sym, and the model is named in the article. The paper expects the differences between models to become visible over time as a comparative record of AI behavior.

• Sellable Biology Board. Search the pest list or filter by a sellable-biology category. Selecting a species loads its sellable biology, buying motives and discovery questions.
• Add-On Services. Bundle reminders to keep in mind as add-ons to the core plan.
• Rep Resource Guide. Frameworks that turn a sighting into a signed program: buying motives, call flow, objection handling, program advantages, conducive conditions and compliance.
• A notice at the end, "Before you use this on a call", sets the limits of use.

• Coverage and Bundling Board. Search coverage lines or filter by buying motive. Selecting a line loads its buying motives, coverage fundamentals and discovery questions.
• Bundle Add-Ons. Reminders to keep in mind as add-ons to a core policy.
• Rep Resource Guide. Frameworks that turn a quote request into a bound policy: buying motives, call flow, objection handling, program advantages, life-event triggers and compliance.

• 27 items of load-processing procedure.
• Reference data for values used across load processing, to be verified against current carrier contracts before use.
• Glossary of internal shorthand and industry terms.

The build flagged three gaps for a process owner to resolve.

• No documented process for partial shipments or split deliveries.
• The $300 detention approval threshold has not been confirmed as current since the last rate review.
• No documented escalation path when a shipper disputes a rate after the rate confirmation is signed.

• Map views for region, tick pressure and mosquito pressure. Pressure views are shaded light to dark.
• A state brief with tick species, mosquito species, associated diseases, peak season and talking points.
• Rep resource guide. Six value props, six answers to common objections, a seasonality table for tick nymphs, tick adults and mosquitoes, and a short guide to using the tool.
• A compliance line: reps state disease risk factually, do not diagnose, and do not promise health outcomes.

Vector ranges, species and disease associations compiled from U.S. CDC surveillance and state health-department data (2023 to 2026). The tool tells reps to verify current local advisories at cdc.gov/ticks and cdc.gov/mosquitoes before quoting specifics to a customer.

• Map views for region, mouse pressure and rat pressure.
• A state brief with mouse species, rat species, associated diseases, peak season and talking points.
• Rep resource guide. Six value props built on CDC's Seal Up, Trap Up, Clean Up plan, six answers to common objections, a seasonality table, and a short guide to using the tool.
• A compliance line: reps state risk factually, do not diagnose, send anyone with symptoms to a healthcare provider, and refer heavy-infestation cleanup to qualified crews.

• Hantavirus counts are CDC's cumulative cases by state of exposure through January 2016, the last state table available. CDC reports 890 U.S. cases through 2023 but publishes the newer map by state only.
• CDC does not publish a state rodent-pressure index. The 1 to 4 pressure tiers are directional composites built from Census American Housing Survey home-sign rates (national average 11.6% of homes), climate, housing age, urban density, species ranges and CDC-documented disease.
• Tiers for states without a published figure are estimates.
• The seasonality calendar is a field rule of thumb, not a CDC table.

• Ten steps with a progress counter and a reset. Work in order or jump from the list.
• About 30 to 45 minutes if done in one sitting. No coding experience required.
• By the end the learner has written a script, stored data in variables, made decisions, repeated actions, organized code into functions, worked with lists, touched a file, and handled an error on purpose.

• Six steps with a progress counter. Steps 1 to 4 are done in Google Forms in another tab.
• At Step 4 the user has the form's entry IDs and URL, which are the two things the sign-off tool needs to send real records.
• The final step confirms the sign-off tool is sending real records to the compliance team's spreadsheet.

• Three example tracks: general onboarding, a specific job process, and a safety procedure.
• "Mark complete" means the employee opened and read that specific step, not that they clicked through a slideshow.
• A record at the end of each track lets a company state that every new hire saw every step of every process at their own pace.

• An opening food safety check and a closing check covering shutdown, cash and security.
• Each check is done one at a time. The final step unlocks after the checks are complete.
• The user enters a name and role (Shift Lead, Manager or Kitchen Staff) and submits one record to compliance.
• Send methods the file offers: the email app (opens a pre-filled message), automatic email through EmailJS, or an inbox through Formspree. EmailJS and Formspree are third-party services that a client would set up for their own use.

• Six checks, each recording an actual reading or result.
• A final step to sign and submit. Submitting sends a single record covering all six checks, not six separate submissions.
• Same send methods and roles as the Daily Sign-Off Hub.

• Absolute or overstated language.
• Confident claims with no citation attached.
• Retired claims still circulating uncorrected.

Whether a claim is actually true, or whether the wrong question is being answered correctly (a referent-scope error). Those need a human or an independent second reader.

• Two modes: Draft, where claim density is expected and collapsed by default, and Final Pass.
• Accepts .txt, .md or .html. The file never leaves the browser and nothing is uploaded.
• Download the report as .txt or copy it to the clipboard. Coordinates are line numbers within the uploaded file.

Chat Tracer reads a corpus of conversations, runs structured analysis operations on it, and produces a saved receipt for every result. It runs entirely on the user's own computer. It contains no network code, never uploads anything, and never calls out to the internet.

• Six commands: trace (find and count), audit (count many terms), compare (compare arms), top (top words and phrases), harvest (draw a labelling sample) and measure.
• Five matching modes: exact, substring, bag (every query word, any order), fuzzy (bounded edit distance) and regex.
• Two views over the same data: Data Lab (the simplified view) and Expert (the same commands with every option visible).
• Source files are opened read-only. Results are never written inside the source folder and never overwrite an existing file.
• Totals from non-literal matching (bag, fuzzy, regex) are suppressed until a validation sample clears the gate. Individual hits are still shown, marked UNVALIDATED.

Chat Tracer ran 50 receipted analysis operations on the sealed corpus (46 completed, 4 stopped by its own safeguards). The Chat Tracer scan counts 1,214 conversations under its own rule, which is not the sealed corpus size of 1,081. Results are on the Findings page.

Data Tracer shares the engine with Chat Tracer: receipts, the hash-chained ledger, licensing and editions, the administrator policy layer, scrub-before-export and a standalone verifier. It works over a folder of general documents instead of conversation turns. It is a separate licensed product with its own command line and window.

• Boolean and proximity search.
• Seeded statistical samples, including sample size and an elusion test (an upper bound on responsive documents a review missed).
• Exact-duplicate detection (identical content only; near-duplicates are not matched).
• Keyword in context.
• Coded review by several reviewers, with disagreement tracked.

NuAegis Tracer is one search-and-measurement engine shared by two shipped products, Chat Tracer and Data Tracer, and by two optional add-ons: a personal-information scrubber and a model-judged labelling tool. Every product reads a corpus once into a small incremental on-disk index, runs every search through the same matching modes, the same windowed scanner and the same precision gate, and produces a signed, hash-chained receipt.

Every command walks the same path: corpus adapter, index (SQLite), matcher, prefilter, read-back with hash check, windowed scan, precision gate, receipt and ledger.

• The index stores locators, dates, counts and a SHA-256 hash of each unit, but never the source text.
• Every result is re-read from its source file and checked against the stored hash before it is shown. If the file changed, the search says so and re-runs.
• Matching runs over bounded, overlapping windows (4,000 characters with 200 of overlap), so one huge document cannot block a report.

A literal search (exact or substring) is a fact: the engine counts matches. A non-literal search (bag, fuzzy, regex, or a model's own label) is an estimate. Its total is suppressed until a human-labelled validation sample shows the method clears a stated bar. The default is 95% confidence, at least 0.8 precision and at least 50 labelled items. An "explore" lane relaxes the minimum to 10 labels and stamps every total as not citable. Individual hits are always shown, marked UNVALIDATED when the gate has not passed.

An optional add-on lets a client-supplied model, running on the same computer, give each unit a label from a fixed small set. The model is gated like a search: its labels are scored against a validation set, and totals are citable only when the bar is met. The add-on contains no network code, is off by default, and an administrator's policy can switch it off permanently.

An interactive engineering reference, "What happens when you run a search", traces one query through the engine for exact, fuzzy and regex modes. Every box names a real function in the engine source. It is an internal document and is not hosted on this site.

Air gap confirmed, with conditions. No path was found by which the audited files can send data off the computer, start another program, load third-party code or collect data. The audit ran on 2026-09-26 on the owner's Windows 11 computer, fully offline, against source commit 8490950 (tag v1.0.0-msi). The deliverables covered were 2 MSI installers, 4 Windows program zips, 3 wheels, 3 zipapps, 1 standalone verifier and 7 software bills of materials.

For each response, the validator splits it into claims and scores each claim. Claims then pass through four layers:

• Engine (bag and fuzzy search). The Tracer engine searches a SQLite index of the knowledge base using content words only.
• Embeddings. A small embedding model (bge-small-en-v1.5) scores semantic similarity. This layer is deferred, see below.
• Little Brain. A small local model (gemma4:e2b) judges borderline claims and returns a structured verdict and confidence.
• Fail-safe. If Little Brain's confidence is below the threshold, the engine's verdict stands.

Big Brain (qwen3:8b) is the model being validated. It generates answers. It is not currently part of the validation pipeline.

• A contradiction check flagged 50% of verbatim knowledge-base sentences as contradicted. It is now off by default and the rate on those sentences fell from 0.50 to 0.00.
• A pass threshold of 0.50 let a response with one hallucinated claim in three pass. It was raised to 0.90.
• Fuzzy search matched a wrong number ($30 for $29) and marked it supported. The fuzzy fallback was removed from the evidence step.
• The Little Brain prompt asked for free text while the server forced JSON, which produced confidence 0 on every call. The prompt now asks for JSON.
• The claim extractor missed hallucinated sentences built on business verbs such as "integrates". The verb list was expanded.

• The contradiction check, the embedding layer and low pass thresholds, as above.
• The sentence-transformers library crashed on import under Python 3.12 with transformers 5.x. It was replaced with fastembed.

F.L.A.R.E.D. is a blameless, autonomous failure-disclosure framework. It was developed during Project Lemonade Blitz, the final four days of the Cornerstone study period, across roughly 47 sessions. The framework is early. It has been tested by one operator.

Blameless here means a failure is disclosed and logged as soon as it is noticed, without penalty for the disclosure.

The one independent behavioral test run so far did not show that the disclosure behavior transferred into a fine-tuned model. See Stage 3. The framework's own verification mechanism, which checks a claim against an outside source, was not tested there, because the evaluated model had no tools.

The Tracer core uses only the Python standard library, opens sources read-only, and gives the same result every time. Security-conscious buyers choose it for that. Other clients want faster search, deeper analytics or connectors that a zero-dependency core cannot offer. Adding third-party code to the core for everyone would break the promise that won the first group.

Keep the core untouched and provable. Offer a Customization Suite through which a client may enable specific named third-party integrations ("bolt-ons"). For each, NuAegis writes an Integration Interface Assessment: a factual account of how the bolt-on behaves inside NuAegis's own process and data flow. The client, not NuAegis, decides in writing whether to accept the risk of the third-party code itself.

In one sentence: NuAegis stays responsible for what happens inside its own walls, and the client decides, with full and plain information, what to let through the door.

The same model made self-service. A non-technical, seat-licensed user types a request in plain English. An assistant checks it against a map of what NuAegis supports, shows the exact counsel-reviewed disclosure that request requires, and, once signed, updates the client's seat and routes a small billing event to the client's administrator for approval.

The assistant does not decide what is possible. It looks the answer up in a map NuAegis has already built, and acts automatically only when the map has a confident answer. The verification step uses the same evidence-check mechanism proposed for the customer-facing citation checker on the Expansion roadmap.

Each opportunity is scored on how much of it already exists in tested code, not on market size or revenue. Build effort Low means new command-line surface and glue code. Medium means a new data shape alongside existing machinery. High means a genuinely new subsystem.

All thirteen ask the same question of a different audience: is this claim about this corpus true, and can it be proven. The document states that none needs a second engine. They need new report shapes, new input formats, and for the citation checker a faster inline path over the same core.

On financial audit, the document says plainly what is not a fit: general-ledger reconciliation, tie-outs, variance analysis and any arithmetic over the amounts inside a document.

• Auto-classification, ported from Dataset Rig v4.0, covers topic tagging, conversation phase tracking, duplicate and loop detection, named-entity extraction and output-format detection.
• Media capture for Gemini uses the Chrome debugging protocol and applies SHA-256 de-duplication.
• Run counters persist between sessions.

• Filenames follow PROJECT_MODEL_###_YYYYMMDD_HHMMSS, with a per-model download counter.
• Output uses a strict USER, SYSTEM and ASSISTANT turn format.
• Auto-classification tags turns such as forensic extraction, legal generation, strategic roadmap, meta-analysis, role definition, user query, repetition and code block.

Five script options, each pasted into the browser console on an open conversation. Each one expands collapsed sections, waits 3.5 seconds, and collects the page's structural nodes into a de-duplicated list.

• Reasoning only. Collects reasoning nodes and skips chat and code.
• Chat only. Collects conversational text and skips reasoning and code.
• Chat plus artifacts. Adds code blocks inside [ARTIFACT] markers and drops reasoning.
• Chat, reasoning and artifacts. Collects everything with [REASONING_TRACE] and [ARTIFACT] markers.
• Baseline. The original unmodified script that scrapes every structural node.

A one-click console script for Kimi sessions. It pairs each user prompt with its response, separates the thought trace, the Python calls and the final output, and downloads a flat text ledger. It is meant for pages where Kimi's scrolling restrictions block a normal export.

A set of per-platform extractors for hidden reasoning ("thinking") content: Kimi thought and Python sandbox logs, Claude accordion sections, Gemini stage panels and Grok reasoning panels, plus a universal script that harvests the whole loaded conversation from any site.

• Runs on the local machine only (127.0.0.1). Each run takes about 2 to 4 seconds on a capped CPU.
• A scenario can have sensors removed, which sends their readings to NULL (not measured).
• An answer key can be shown for scoring. It is never given to the engine.
• Triathlon: the tool alone, a model with the tool and a model without the tool, on the same scenarios, with a leaderboard.
• Learning experiment: the same model with and without its verified debrief notes. After a failed run the model answers 8 questions and the engine checks each answer. Only a corrected path that names the true answer and passes the physics becomes a preference pair. No model weights change.
• Batch runs: scenarios with 2 to 4 faults at once, at least 2 in the high-pressure section, flown through ice crystals, rain or high humidity.

Two or more players take turns proposing one fault to eliminate or passing. The physics engine referees. Scoring: confirmed +2, rejected -1 or -2, dangerous (a real fault) -5. After the rounds each player makes a final call from the labels still on the board: +4 per real fault, -2 per wrong pick. A match can be downloaded as one self-contained HTML replay that opens offline.

The simulation was built from three parallel sessions: a simulation core that generates physics-grounded scenarios, an adapter that checks answers in three buckets (survivor, indeterminate and eliminated), and a runner that sends scenarios to local models.

A state-machine simulator of stages 0 to 5, with a deterministic mock mode and a mode for a live Gemini API engine. It includes a license gate (a GPL-3.0 source halts the run), a three-pass PII step with a human sign-off and a salted SHA-256 receipt for each redaction, a compliance check that chosen and rejected replies stay within a 2 percent variance, and an export that unpacks one failure into four training rows.

• The page is a control panel. The tracing runs in Python on the user's own machine: the user starts server.py and reloads the page. Nothing is sent over the internet.
• The user picks the job, for example a business card, a laser bed or a heat press, not a settings panel. Each job fills in the trace settings, real printed size, file formats, mirroring and layer structure.
• Each job shows an instruction card of what to check before spending material.

The numbers behind a good trace change completely with the destination, so naming the destination first puts the settings, size, mirroring and layers in place when the file lands.

Double-click the downloaded .html file, or drag it into any modern browser (Chrome, Edge, Firefox, Safari). It opens as a normal web page and works fully offline.

One controlled entry point

Enter one task, select the protocol and assigned folders, then generate a complete ordered brief for the model. The same application provides a desktop window and command-line workflow.

• Preview without writing
• Generate without overwriting an existing session
• Advance the session number only after success

Bring your own protocol

A JSON manifest fixes the rule-file order, phases, required artifacts, evidence rules, prohibited actions and completion checks.

• UTF-8 Markdown, text, JSON, YAML, TOML or XML
• Contained relative paths only
• Every included file receives a SHA-256 fingerprint

Managed research folder

Each run receives a numbered workspace with records for the running log, context, findings, audit and task ledger.

• Separate evidence, outputs and transcript folders
• New JSON receipt for every generated brief
• Append-only master ledger entry

Integration contracts

Describe a tracer, database, local search tool or document workflow in a bounded contract. Prompt Cage inserts the allowed operations, forbidden operations, invocation guidance and required evidence into the brief. It never executes arbitrary integration files. The selected model runtime or deterministic controller performs the real operation and records the result.

Small-model workflow

Use a deterministic controller for folder setup, retrieval plans, tracer commands and receipt verification. Give the model a bounded evidence packet and no more than two high-level actions: request research and submit a cited answer.

• Counts remain deterministic
• Model interpretation stays separate
• JSON mode supports models without native tool calling

BLITZ Lite lets a consumer or independent researcher compare local model answers, repeat the same prompt in a named trial, and save each conversation and provider response record on their computer. It supports Ollama and LM Studio, and the package includes a step-by-step user guide.

• Compare up to 3 models on one prompt
• Repeat a named experiment 1 to 5 times per model
• Capture prompts, responses, provider metadata, token counts when reported, timing, and review results in local JSONL records
• Export Markdown, CSV, or JSONL
• Optional automatic second-model verifier and reviewer
• MIT License. No model weights or provider runtime included

The master Lemonade Blitz extraction covers 30 sessions and catalogs 1,175 curated examples. Its manifest identifies 27 examples in the F_PREVENTION_SPRING category, while the on-disk event file contains 3,867 framework marker lines. These are different counts: examples, category examples, and marker lines.

• NuAegis archive scope: 1,081 conversations, 110,191 messages, about 69.1M tokens, 10 accounts, and 5 model families. Sealed 2026-08-04.
• The extraction manifest reports 3,486 files; its present session subtree contains 3,489 files.
• FLARE's compressor exercise reported agreement between two implementations on fault-set membership. This measures implementation agreement, not accuracy against independently confirmed causes.