Updates

Marnie's core orchestration has been fully rebuilt around a deterministic 4-phase pipeline that replaces the previous iterative loop architecture. Runs are now faster, more consistent, and produce cleaner findings with fewer false positives.

• Phase 1 — All six reviewers analyze your manuscript in parallel simultaneously and generate structured critique packets (IssueObjects). This replaces the 3-reviewer-per-loop rotation. Every reviewer contributes to every run.
• Phase 2 — An independent auditor adjudicates packets from the first three reviewers. Each packet either receives explicit support, is omitted with a reason, or triggers a one-shot clarification request back to the originating reviewer.
• Phase 3 — The same adjudication process runs for the remaining three reviewers' packets.
• Phase 4 — Supported and omitted findings are consolidated into your report. Nothing is discarded silently — omitted findings are logged separately.

Runtime has dropped to approximately 2–3 minutes for full manuscripts. The activity panel now announces each phase in real time as it begins, with per-reviewer progress during Phase 1.

Monthly run counts have been replaced by a cumulative token budget. Rather than capping the number of reviews you can run, Marnie now tracks total token consumption across all your runs and measures it against your account's budget.

• All active accounts have been set to a 500,000-token starting budget. Based on the new architecture's efficiency, this is expected to cover a substantial number of full-manuscript reviews — exact averages are being measured as the new pipeline accumulates run data.
• Token usage is displayed live during every run and recorded per-run in your history.
• When your budget is approaching its limit, a warning will appear in your account. Contact support to request additional budget.
• Budgets will be automatically recalibrated as real usage data accumulates, so the ceiling will adjust to reflect actual consumption rather than conservative estimates.

Marnie is now accepting access requests. You can create an account from the sign-in page — access is manually reviewed and granted by the creator. If you have a manuscript you'd like reviewed, request access and you'll be notified once approved.

Marnie's storage layer has been migrated from SQLite to PostgreSQL, hosted on Neon. Run history, user accounts, and issue registry data are now stored on a persistent, replicated database that survives redeploys without a mounted volume.

Time elapsed and total token count now appear in the overview summary on the findings report — alongside loops run, convergence status, and finding counts. Both values are also included in the markdown export. Metrics are stored per run so opening a previous run from history shows that run's numbers.

Removed all panel boxes, card chrome, and white surfaces. The interface now sits directly on the background with hairline rules for separation. The textarea, upload zone, select inputs, topbar, and footer all blend into the background colour. The progress bar is a single 3px line.

Replaced the raw terminal log display with a plain-English activity panel showing what Marnie is doing and why at each phase. Each pass appears in a live feed that completes as the loop finishes. Rotating messages explain concepts like evidence grounding, multi-agent agreement, and convergence logic — one phase at a time on a 12-second cycle, independent of loop cadence.

A mm:ss timer starts when you click Run Marnie and stops when orchestration completes. A token counter updates once per second throughout the run. Both are displayed as a subtle monospace line inside the activity panel during active runs only.

Two parallelisation improvements reduce time-per-loop:

• Verifier calls now run in parallel (up to 5 concurrent) instead of serially. For a loop with 15 issues, this alone can save 30–60 seconds.
• The InterloopAuditor is dispatched to a background thread while the Judge runs synchronously, so both complete in roughly the time of the slower one rather than their sum.

The findings report moved from a card grid to a structured document layout. Findings are grouped by severity then category, rendered as document rows with left-rule severity indicators. The PDF export (Print / Save) produces Times New Roman 12pt double-spaced output suitable for academic submission, with proper finding borders, evidence blockquotes, and a summary grid.

The maximum configurable loop count was reduced from 50 to 15. In practice, Marnie converges between 5 and 10 loops on full manuscripts. The old ceiling was theoretical headroom that created risk of runaway runs. The default remains 12.

Replaced binary convergence gates with a continuous readiness score computed each loop from six weighted signals: registry growth stall, registry hash stability, critical issue resolution, agent consensus depth, coverage breadth, and loop ceiling pressure. Convergence fires when the score holds above a threshold for two consecutive loops. This eliminated false-early terminations and runaway loops simultaneously.

Every issue family receives a 0–100% confidence score computed from six additive signals: instance count (multi-agent agreement), validation rate, loop survival, evidence quality, field relevance, and auditor confirmation. No LLM calls — deterministic and fast. Scores are written to the issue registry and displayed on the findings report.

Individual issue instances raised by agents are clustered into families using cosine similarity (threshold ≥ 0.82). When multiple agents independently raise the same concern, their instances are grouped rather than duplicated. Only validated or inferential families surface in the final report — the registry acts as a persistent deduplication and confidence layer across all loops.

Replaced free-text critique generation with a machine-parseable IssueObject schema. Every finding now requires a precise claim, a support type (direct, inferential, or global), an exact quoted span for direct evidence, a location, a severity, and a category. Agents that cannot produce a grounded finding return an empty list rather than vague prose.

A dedicated verification pass runs after each loop's agent outputs. Five rules are applied per issue: the span must exist as a literal string in the manuscript, a second LLM call confirms the span actually supports the claim, duplicate detection across families, and a vagueness check that downgrades ungrounded claims to inferential. Issues that fail are marked unsupported and do not reach the report.

Each loop selects 3 reviewers from a pool of 6 specialists — Judge, Editor, Verifier, Methodologist, Domain Specialist, and Epistemologist — using weighted round-robin to ensure all roles appear before any role repeats. Agents run in parallel and work from the full manuscript independently, with no cross-contamination between reviewers. At least 4 unique roles must appear before convergence is permitted.

Initial system: six specialist agents (Judge, Editor, Verifier, Methodologist, Domain Specialist, Epistemologist) read a manuscript and produce structured critiques across multiple passes. The Judge consolidates each loop's findings. The InterloopAuditor tracks coverage across passes. Outputs are critique-only — Marnie never rewrites or drafts.