Every commit, with its name, date and time, and what changed.
v0.11Current
feat: the super admin can turn two-step verification off, and back on, for everyone while the product is built and tested
While Ringo is being built and tested, two-step verification gets in the way. The super admin can now turn it off for everyone on the platform, including themself, and turn it back on, from the operations console (Users, 'Two-step verification for everyone').
Off means the server stops requiring a second factor: staff access, workspace roles that need one, and creating a workspace. Anyone who has an authenticator can still use it. An optional box also removes everyone's authenticator at Google, so enrolled people are no longer asked for a code at sign-in; they can set it up again later.
Every change needs a recent sign-in and a written reason, and is recorded in the staff audit with who and when. Turning it back on ends staff sessions that never used a code (except people with their own waiver). Only a super admin can use it. If the setting can't be read it counts as required, and an environment set to optional still wins. The console shows a clear warning while it is off, and the system check shows the state.
The default is unchanged: it stays required until the super admin turns it off. Migration 027. New tests (backend 265 passed, frontend 97).
v0.10f41ed36a
feat: the SDKs check what leaves - a guard that redacts secrets and personal data before an answer is sent, and a preview that shows each answer for the person to send, edit or withhold
The owner's question was how to make sure an orchestrator does not tell Ringo everything it knows. Ringo already refuses credentials and anything outside the grant on her side; now the Python and TypeScript SDKs (0.2) check everything inside the orchestrator's own process, before it is sent.
Guard, on by default: secrets (provider keys, tokens, JWTs, private keys, password= values, credentials in addresses), card numbers (checksum-verified), emails and phone numbers are replaced with a marker. Israeli ID numbers, IBANs and IP addresses can be added. Callers list words that must never leave (names, code names), add their own patterns, and can make a kind stop the whole answer, in which case the request is answered as withheld and Ringo records the gap. It reports what it found by kind and field, never the values.
Preview: every answer that carries text is shown after the guard, and a person (in the terminal) or the caller's own function decides to send it, edit it (the edit is checked again) or withhold it. With no terminal it withholds, so an unattended run never sends what nobody saw. Answers that carry no text are not asked about.
Everything leaves through one place, so answers, evidence, maps, messages, implementation and outcome reports, decisions and the opening question are all covered. The setup steps in the app and the prompt for the agent now show how to turn it on. Detection is pattern-based and cannot recognise a trade secret that has no recognisable shape; the documentation says so. New tests in both languages (backend 259 passed with the SDK tests, frontend 96).
v0.9c968de63
feat: connecting the key - after creating a connection the owner gets the key with three steps (store it, hand the orchestrator its instructions as a prompt or code, check it connected live)
Until now the owner saw the key with a warning to keep it safe and nothing about what to do next. The key dialog is now a short guide: store the key as an environment variable or in the orchestrator's secret store; give the orchestrator its instructions; and check that it really connected.
The instructions come in four forms: a prompt to paste to the AI agent or coding assistant that builds the orchestrator (it never contains the key; it tells the agent to read the protocol, call the check endpoint first, answer only what Ringo asks and to withhold anything it is unsure about), and ready code in Python, TypeScript or curl that reads the key from the environment.
A live check shows 'Waiting for the orchestrator's first call' until it calls, then 'Connected' with the time. A connection nobody has called yet shows the same notice on its card with a button to reopen the steps, and the steps stay available later. Screen change only; the API is unchanged (image v32). New test for the setup steps.
v0.8e6707564
feat: decisions from research - risk tiers, review floors with independent and trained reviewers, declarations that say how, builder commitments, guide completion record, environment checks for data and training, stronger personal-data attestation, legal notes for counsel
The three open questions about the path to trust were researched and answered, and the answers are now rules in the product. Sources and reasoning are in docs/legal/PATH_TO_TRUST_LEGAL_NOTES.md, written as working notes for counsel, not legal advice.
Risk-proportionate gates: every system gets a risk tier (low, medium, high) from how much it can do on its own and what data and reach it has. Builders say which data classes a system touches and who it reaches (themselves, a team, the organisation, outside). Higher tiers need more before the next step: stop controls, approvals, no high findings, and for high-risk systems a trained builder.
Second-person review floors: medium-risk systems need an independent review before daily use and high-risk systems before the pilot, whatever the workspace rule says. The reviewer must be a different person who has completed the guide and, for high risk to daily use, an owner or admin. Approving means ticking four things: open items, tests, the dossier, and data and reach.
Declarations by the team must say how the claim was established (at least ten characters) and stay on the record with who and when. Moving a system to pilot or daily use needs the builder to accept a short list of commitments, stored with the version of the text.
A record of who finished each lesson in the Builder's guide, shown to owners and admins, as the organisation's evidence of AI literacy.
Approved environments now also say which data classes a tool may hold, whether the provider trains on inputs and how long it retains them, and the check fails a system that puts sensitive data in a tool that does not cover it or trains on it.
The personal-data attestation for orchestrator links now needs three confirmations (purpose, covered by the unit's policy, authority) and a written basis of 20 to 500 characters. Migration 026. New tests for all of it (backend 249 passed, frontend 89 passed).
v0.7a8139a11
feat: the path to trust - a clear route from a prototype someone built to a system people can rely on every day (stages, readiness check, test plan, mentor, review, approved environments, builder's guide, unit overview)
A route for builders, not only engineers: every system now sits at a stage (prototype, pilot, in daily use) with a plain readiness check for the next step. Each item says what it checks, what to do, and who vouches for it: Ringo (from records she holds), the team (declared, with who and when) or another person.
A test plan generated from the system map (real examples, asking for something it must refuse, hidden instructions in data, a dependency down, loops that must stop, rollback) that the builder works through and records, with failures and exceptions explained.
Accompaniment and control: a mentor per system, and a workspace setting that requires a second person's review before pilot or daily use, which not even an owner can skip. Moving on with required items open is possible only for an owner or admin, with a reason, and stays on the record.
Approved environments: owners and admins list the models, tools, platforms and data sources people may build with, and the check compares each system against the list. The Standards page, the Builders overview (every system, its stage, what blocks it, reviews waiting) and a six-lesson Builder's guide (define the problem, plan, test, pilot, earn trust, work with Ringo) are in the app.
The advice an orchestrator reads now says where its system stands on the path and what a person would still need to see. Fixed: deleting a case or workspace that holds orchestrator data would have failed on the newer tables, and so would the retention clean-up for such cases. New tests cover the path, the review rules, the standards, deletion of orchestrator data and the screens (backend 242 passed).
v0.6.263cf3b8d
fix: the API test that opened its own database connection now uses the configured one, so the new CI job passes on GitHub
The first run of the new CI job for the API showed one test that connected to the database with a hard-coded address and the machine's own user name. It now uses the configured owner connection, like every other test, so the whole API suite runs on GitHub as well as locally.
Documentation of what was added in 0.6 (retention, webhooks, SDKs, antivirus sidecar, staging, monitoring) is part of the partner document, which was rewritten for this version.
v0.6.1b5bd877a
fix: summary writer borrows the second reader's route, monitoring script works on machines without Python certificates, worker deploy keeps the antivirus sidecar
The plain-language summary of a dossier is written by AI again: its agent had no route of its own in production, so it now borrows the second reader's route until it is routed separately (an own route always wins).
The antivirus sidecar is live on the production worker and proved itself: the scheduler's self-test scan of the standard test file is flagged by ClamAV. Deploying a new worker image keeps the sidecar (scripts/ops/antivirus.py moves the worker to a new image).
The monitoring script now works on any machine, and outside monitoring is in place in production: uptime checks on readiness and the home page, with alerts for those and for server errors.
v0.616e7ce22
feat: close the open gaps - retention, signed webhooks, SDKs, antivirus sidecar, staging, monitoring, CI for the API, implementation and owner screens, safer start-up
Retention now works (spec OPS-002): a case's content is deleted 365 days (or 90 if shortened) after the last real activity, with in-app warnings at 30 and 7 days and the exact date on the case; finished jobs, abandoned uploads, expired exports and old logs are pruned on schedule.
A connected orchestrator can be told instead of polling: signed webhooks (ids only, retried with backoff, never to private addresses, switched off after repeated failure) with a panel for owners to set, test, renew and inspect them. Python and TypeScript SDKs, a runnable reference orchestrator and a self-describing OpenAPI document for the channel.
Antivirus: ClamAV now runs as a sidecar of the worker, the scheduler has it scan the standard test file every minute, and the console reports that proof instead of just a setting.
A staging environment (own database, buckets, queue, secrets, services and Hosting site) created by one script; outside monitoring with uptime checks on a new readiness endpoint and alerts for readiness, home page and server errors; CI now runs the whole API suite on PostgreSQL.
Report screen: record what was implemented, name decision and implementation owners, and see what changed since the previous dossier.
The API and worker refuse to start in production or staging with development secrets or local back ends; the interviewer AI borrows the discovery agent's route until it is routed on its own; a new ai-status command shows what is routed; the event stream asks the database less when quiet; README and architecture documents rewritten to match reality.
v0.5.1b9915728
fix: orchestrator channel fully wired - analysis tracking, waiting for evidence review, gaps in the dossier, grant changes applied at once, expiry, cancel, poll allowance, room and notification links
Ringo now follows the analysis whoever starts it: the interview moves to analysing and delivered, reports a paused, failed or cancelled run to the owners, and picks up an analysis a person started.
Ringo no longer analyses without evidence the orchestrator sent that a person has not reviewed yet: she says so, tells the owners and carries on when it is approved. Evidence a person excludes becomes a recorded gap.
Everything Ringo could not get (outside the grant, withheld, not answered, excluded) is written into the dossier's own gaps, so the report says what it could not assess and why.
Changing a connection's grant applies at once: requests Ringo may no longer ask are closed, new ones are reopened. Resuming a paused connection or extending an expired one continues the interview; an expired connection stops it.
The orchestrator can stop a running analysis, waiting for Ringo (long polling) no longer uses up its request allowance, and its inbox no longer carries the human-directed next-step notes.
The consultation room shows an interview card (status, round, what it waits for, gaps), evidence from an orchestrator is badged, notifications link to the consultation, map and connection, and the audit trail names orchestrators.
New tests cover each of these paths, including a person approving or excluding evidence mid-interview, pausing and resuming, narrowing and widening the grant, expiry, a person starting the analysis, pinned cases, follow-up reporting and the full AI team working on an orchestrator's evidence (backend 192 passed).
v0.5f3aff0d5
feat: orchestrator channel - Ringo advises the client's AI orchestrator directly (grants set by a person, interview, evidence pull, advice by component, report-back and follow-up)
The client is now the AI agent. A person connects the client's orchestrator to Ringo (system page, new Connections tab) and decides what it may share (structure, logs and figures, or personal data with an attestation) and what it may do, with limits on rounds, evidence volume, analyses and cost. Credentials and card numbers can never be shared.
Ringo interviews the orchestrator directly: she asks for what the consultation question needs, one batch at a time, pulls answers, a system map and evidence through the machine API (/v1/agent), and records anything it can't or won't share as a gap. An optional AI interviewer can sharpen the requests; everything it writes is checked in code.
Evidence inside the grant is approved for analysis automatically; anything else waits for a person, and the owners are notified. Ringo starts the analysis herself only within the grant's run count and cost ceiling.
The dossier comes back to the orchestrator as ringo.advice.v1, grouped by the agents inside its orchestration, with verification plans and no commands. The orchestrator reports what it implemented and measured and can open a follow-up round that builds on the dossier.
Keys are shown once and can be paused, rotated and revoked at any time; every machine action is audited with its own actor kind and shown in a per-connection activity feed. A kill switch pauses the whole channel. The consultation room marks the orchestrator's messages and lets a person answer for it.
New tests cover grants, keys, scope refusals, limits, auto-approval, the end-to-end interview, injection resistance and the screens (backend 180 passed).
v0.4b60b3923
feat: version number in the header and a version history page
The header now shows the version (v0.4) on the website, in the product and in the operations console; it links to the new Version history page.
Version history lists every commit with its name, date and time, and an explanation of the changes and updates.
Rule from now on: every commit updates the version number and adds its entry to the history; a test enforces it.
v0.37ab4dded
feat: protected founding owner (nobody else can edit, block, delete or re-role it), direct landing in the operations console after Google sign-in, per-person two-step waiver (including self) with provider-side authenticator removal, owner-status check
The founding owner (rotgolan@gmail.com) is protected: nobody else, including another super admin, can edit, block, delete, sign out, re-role or change the two-step setting of that account, or remove it from a workspace.
Signing in with Google on the normal sign-in page now sends staff straight to the operations console.
A super admin can turn two-step verification off (or require it again) for one person or for themself; it is audited and also removes the authenticator at the sign-in provider.
New owner-status check and an end-to-end test of the sign-in-to-console path.
v0.337b47e3b
feat: close known gaps - email delivery (provider set-up, verified test send, invitations emailed), optional ClamAV scanning (fail closed) and EICAR check, Skeptic fix round, team-vs-single-model baseline, mobile staff menu, axe accessibility audit, lint and hygiene cleanup
Email delivery: Resend or SMTP set-up in the console, a verified test message before it can be switched on, invitations emailed with a one-time link (the link is never stored), a send log without addresses or content.
Optional ClamAV antivirus scanning that fails closed, plus detection of the standard EICAR test file.
Skeptic fix round: an advisor may revise or withdraw a finding after a material objection; the dossier shows what was answered or withdrawn.
Advisory team versus a single model comparison in the evaluation lab; grouped mobile menu for the staff console; automated accessibility audit (axe) with fixes; lint and hygiene cleanup.
v0.339f1ca0a
feat: agent audit (spec conformance, scorecards and drift, safety suite, golden evaluation and A/B, review queue), canary prompts, per-agent limits, clone and archive, flow, reliability and retention dashboards, AI spend forecast, user segments, bulk actions, notes, export, platform sessions, invitations and look-through log
Agent audit: conformance to the product spec, scorecards and drift detection, safety suite, golden evaluation and A/B comparison, human review queue.
Canary prompts, per-agent daily limits, clone and archive for custom agents.
Dashboards for consultation flow, reliability and retention; AI spend forecast; user segments, bulk actions, internal notes, CSV export; platform sessions, invitations and the look-through log.
v0.3fbfa3109
feat: advisory team (Ringo, Argo, Metric, Skeptic) with a reasoned planner, Skeptic review, case framer and evidence planner, sharper locked-contract prompts, client domain context, design-system charts, orchestration map, advisor board in dossier and consultation room
The advisory team (Ringo, Argo, Metric, Skeptic) with a reasoned planner that decides who works and why, Skeptic review, case framer and evidence planner.
Sharper prompts with a locked contract (advisory boundary, untrusted-material rule, evidence rules), client domain context, design-system charts, an orchestration map and an advisor board in the dossier and consultation room.
v0.33585b1a6
feat: super-admin situation room, agent studio (versioned prompts, sandbox, custom specialists), consultation playbook, connections and health history, audited label reveal, user activity
Super-admin situation room across projects, users and consultations; agent studio with versioned prompts, sandbox testing and custom specialists; consultation playbook.
Connections and health history, audited label reveal, per-user activity.
v0.367f73c97
feat: finance, spend caps, plans and manual grants for super admin (no payment processor), alerts, route tools, customer AI usage, sole-operator rule
Finance for the super admin: revenue and AI cost, spend caps, plans and manual grants (no payment processor connected), alerts, route tools, customer AI usage, and the sole-operator rule.
v0.3dc1e46ab
feat: OpenRouter AI integration - super-admin key + per stage/topic model routing, consent-gated verified AI findings, real-cost accounting, graceful degradation
OpenRouter integration: the super admin enters the key and routes models per stage and topic.
Consent-gated AI findings that are verified against the customer's own material, real cost accounting, and graceful fallback to the rules route.
v0.342c5f09e
docs: super admin and user administration
Documentation for super admin and user administration.
v0.3ae9fb925
feat: super-admin user administration (create/edit/block/delete, memberships, staff roles, sessions), audited read-only view-as, system check, CLI
Super-admin user administration: create, edit, block, delete, memberships, staff roles, session control, audited read-only view-as, a system check and a CLI.
v0.261a0bbbb
test: ownership transfer; deploy
Test for ownership transfer; deployment.
v0.2d5e58369
feat: ownership transfer screens; runbook verification notes
Ownership transfer screens and runbook verification notes.
v0.2bed5ac6f
fix: owners can edit maps; map confirm control; mobile header; real-data e2e
Owners can edit system maps, clearer map confirmation, mobile header fix and a real-data end-to-end test.
The product web app: sign-in, workspaces, systems, cases, evidence, consultations, dossiers, billing sandbox and the operations console, plus pricing and security pages.
