Open source · Multi-model AI · Supervised work

From business problems to software you can check.

You know where the work gets difficult. You don’t need a technical specification to start.

Ontinuity supports the path from an initial conversation to a defined problem, a buildable plan, and tested software. It combines persistent project records with AI-assisted development and separate model review, so decisions and results can be examined as the work progresses.

Explore the work →Discuss a problem

Available today through supervised working sessions.

Applied work

Two problems. Concrete progress.

A business workflow and an engineering question show how clarification, implementation, and adversarial review contribute at different stages.

Home care · Problem definition & development

Making emergency shift coverage easier to coordinate

A home-care agency needed a better way to match available caregivers to open shifts. Structured intake became a problem definition, a solution proposal, and a staged build plan covering matching, outreach, acceptance, and schedule updates.

Protected client records created a development barrier. SantaClean, a local de-identification tool, was built to prepare data for development while keeping original records on the owner’s computer. A deterministic matching prototype has also been built and tested.

Current stage: SantaClean is working and awaits the owner’s evaluation. The full scheduler remains planned; further integration awaits her export and final input.

Explore SantaClean →

Control systems · Technical investigation

Turning a cornering question into a technical specification

A vehicle cornering problem, initially described in everyday language, was developed into a control-systems specification through Ontinuity’s adversarial multi-model process.

Separate model review identified a mathematical defect: a calculation could divide by a value approaching zero. Catching it at the specification stage made it possible to address the issue before implementation. The process made the investigation attainable without outside specialist consultation.

Result: a technical specification and a review finding. Vehicle implementation and real-world validation are separate stages.

Ask for a project walkthrough →

How it works

A clear next step at each stage

The business owner contributes the context. The process turns that context into decisions, requirements, and work that can be checked.

01 · Understand

Describe the work

A guided conversation captures the current process, the difficulty, and what a useful result would look like. The owner corrects and confirms that understanding.

02 · Define

Separate facts from assumptions

Record the problem, constraints, and unanswered questions. Keep confirmed information distinct from assumptions that still need checking.

03 · Plan

Agree on the scope

Develop a proposal, divide the work into buildable stages, and establish how each stage will be evaluated before implementation begins.

04 · Build & review

Produce and check

Implement each stage, test it against the agreed criteria, and have a separate AI seat challenge the result. Preserve the findings and remaining work.

Current availability: guided intake and supervised project work. The home-care project has reached planning and working components; a self-service product and its complete scheduler remain future work.

The supporting system

Continuity, challenge, and a checkable record

Persistent context

Project records preserve decisions, constraints, and unfinished work across sessions. A new model can read the record before continuing.

Adversarial review

Separate AI seats challenge the work and its supporting evidence. Using different models creates opportunities to uncover mistakes and unsupported assumptions.

Explicit checks

Written criteria and recorded checks govern completion. The record lets a reviewer trace what was proposed, checked, corrected, and left open.

Checks are only as useful as the criteria and evidence behind them. Passing a defined check does not establish that every possible defect has been found.

Evidence & research

Examine what the process changed

A useful review changes the work: an assumption gets challenged, an unsupported claim needs evidence, or a defect gets caught before implementation. Those outcomes are the evidence to examine.

Recorded review examples

The technical account describes sessions in which completion was refused until the work supplied a quotation, a cited mechanism, or an applicable edit. It also discusses the limits of the system.

Read the technical account →

Contact

Start with the problem you’re working on.

For a business workflow, a technical investigation, or research collaboration, describe the situation and what you’re trying to accomplish. You can also arrange a walkthrough of the existing projects and their supporting work.

Start a conversation →About the builder

contact@ontinuity.org