Foundational Synthesis · v1.0 · April 2026

A research operating system, end to end.

Each work session creates knowledge. That knowledge is saved, so the next session starts sharper than the last — and a live workspace lets the system act on what it figures out, not just talk about it. That’s the whole loop. This paper walks through it: what it is, how it works, what it has shown, and where it goes.

The capstone of the Ontinuity corpus · the full synthesis · doors into every paper · ~35 min full read

Foundational document · April 2026

This is the original synthesis — the capstone of Ontinuity’s foundational architecture. As a description of the system that runs today, it has been superseded by the current-system synthesis, Reliability Without Trust. Read this for the foundation; read that for what runs now.

Synthesis · v1.0

Ontinuity

A research operating system — cognitive infrastructure for sustained AI-assisted work

Patrick Killebrew · May 2026 · Synthesis paper

Abstract

Ontinuity is a system for doing serious work with AI over a long time — work that spans days, weeks, or months rather than a single conversation. It exists to solve four problems that show up whenever that work gets real.

The first is that AI forgets: when a conversation ends, everything you established is gone. The second is that AI models tend to agree with each other, so when two of them work together, errors slip through instead of getting caught. The third is that the human ends up waiting — stuck approving routine steps the AI could already take on its own. The fourth is access: getting rigorous technical answers normally takes either deep expertise or money for someone who has it, which keeps most people on the outside.

Ontinuity answers each with a specific part. A four-model adversarial session protocol (Tetraform) makes the models challenge each other instead of agreeing. A session navigator (the Parietal) decides which moments actually need a human. A project-level knowledge keeper (Projenius) and a portable memory document (Knowtext) carry what was learned from one session into the next. And a local workspace lets the AI act on real files, not just descriptions of them. Together they close a loop: sessions create knowledge, the knowledge persists, and each session starts sharper than the one before.

Throughout, this paper is careful to separate three things: what has actually been observed, what has been modeled but not yet tested, and what is still an open question.

Contents — jump anywhere

  1. IWhy This Exists — the four problems
  2. IIHow Ontinuity Works — the five components
  3. IIIWhat It Can Do — real examples
  4. IVThe System Today
  5. VSafety
  6. VIWhere This Is Going
  7. AAppendices — papers, schema, glossary

Part I

Why This Exists

Every component in this system exists because a specific problem required it. This section describes four problems — not as technical categories, but as experiences anyone who has worked with AI on something serious will recognize.

1.1  The Fresh Start Problem

Open a new conversation with any AI assistant and it knows nothing about you, your project, or the work you did together yesterday. Every session starts from zero. A correction you established last Tuesday — something you spent an hour working through — is gone. A decision that took three conversations to reach has to be rebuilt before you can use it. For a quick question, that’s fine. For a project that runs weeks or months, the reset is a real cost. The usual workarounds — pasting in summaries, keeping notes, writing system prompts — all put the work on you, and none of them fully bring back what was lost. So the question is simple: can the context of a long collaboration be saved automatically, in a form any AI can pick up, without you having to carry it? Knowtext is the answer.

1.2  The Agreement Problem

When two AI models work together, they tend to agree — and that’s a real risk. Think about what each choice costs a model reviewing another’s work. To challenge, it has to find a specific flaw and explain exactly what’s wrong with it. To approve, it only has to see nothing obviously broken. The easier path is to approve. It gets worse when both models share the same context: they read the same ambiguous evidence the same way, so a mistake that comes from that shared view sails through — both have the same blind spot. The review looks rigorous, but it isn’t really independent. Fixing this takes two things: models with genuinely different training put in opposing roles, and a way to settle their disagreement that doesn’t let either one simply overrule the other.

1.3  The Waiting Problem

Watch a person work with an AI on a complex problem for an hour and for most of that hour one of them is waiting. The human judgment in this loop is not evenly valuable across every turn: some turns require genuine judgment — a direction decision, an alignment check, a values question — but most are routine progress cycles where the next step follows naturally from the last. The loop cannot continue without the human because nothing currently decides which turns require judgment and which do not. For complex work that could run dozens of cycles, the human becomes the bottleneck in a loop effectively waiting for permission to do what it already knows how to do.

1.4  The Access Problem

Getting rigorous, engineering-quality answers to hard technical problems takes one of two things: the expertise to produce them yourself, or the money to hire someone who has it. That gate — expertise on one side, money on the other — keeps most people on the outside. It isn’t that the work itself is scarce. It’s that the tools for reaching real expertise still require either a trained person or an expensive engagement. So here is the question worth asking: what would it mean to lower that gate — far enough that anyone who can clearly describe a problem has a real path to a rigorous solution, without needing a degree or a big budget to get there?

Part II

How Ontinuity Works

Ontinuity is five components working in a closed loop. Each exists because a specific problem required it.

2.1  The Design Philosophy

The founding principle is that every component must earn its existence by solving a specific problem the others cannot. There are no features in this system — only answers to questions. A second principle is promptgramming — configuring AI behavior through structured, precise prompting rather than fine-tuning weights. A promptgrammed component is a model given a specific role, a defined set of callable functions, and precise instructions for how each executes. This matters because such components can be updated, tested, and replaced without retraining: the architecture is not locked to any model or provider. The deeper account of this method is the Artificialware paper.

2.2  Tetraform — The Session Layer

Tetraform structures how a working session runs, using four models in distinct roles. The Researcher is the primary engine — generating analysis, producing specifications, driving toward the objective. The Challenger reviews the Researcher’s output each cycle and challenges genuine errors, unsupported claims, or logical gaps; the critical design choice is that it has a different training background, because the errors most likely to slip through are the ones both models share. The Friction model observes from outside the working conversation and outputs a single number from zero to four each cycle — a health score that appears in the others’ context but is never spoken aloud, changing their behavior without entering their dialogue. Anything that enters the conversation becomes part of what the models reason about; the friction signal produces influence without adding noise. The fourth role is the Parietal.

2.3  The Parietal — The Session Navigator

The Parietal is a promptgrammed role with four callable functions — the session-level consciousness that holds the shape of the session at the highest level of abstraction. PRE_SESSION fires before the loop starts, asking at most two clarifying questions and outputting a refined objective. NAVIGATE fires at every human touch point, presenting four structured fields — where the session is trying to get, where it stands, what is immediately ahead, and one precise question — so the human sees synthesized orientation, not a transcript. ADJUDICATE fires when the Challenger issues a formal challenge, ruling to pursue both paths in parallel, uphold, reject, or escalate to the human; escalation is limited to four conditions (a challenge to the foundational premise, both paths viable after extended development, significant drift, or a values judgment). DISTILL fires at session end, producing the updated Knowtext that closes the loop between sessions.

2.4  Projenius — The Project Memory

The Parietal knows what happened in today’s session; Projenius knows what the project has established across all sessions, branches, and accumulated time. Its primary responsibility is the Established Results Ledger — a structured registry of every conclusion reached with enough rigor to be treated as established, each entry recording the result verbatim, the session that established it, its branch, a confidence level, and caveats. When a later session overturns a prior result, the retraction is recorded alongside the original with its grounds; nothing is silently deleted. Projenius also serves ORIENT (project context before each session) and LEDGER_QUERY (finding prior results relevant to a current question, so work does not unknowingly repeat itself).

2.5  Knowtext — The Memory Document

Knowtext is a structured memory schema that carries the accumulated understanding of a working relationship across sessions, platforms, and time — the answer to the fresh start problem. The constraint that shaped it was portability: it is plain structured text, usable by any AI that can read text, pasteable into any conversation, editable directly, requiring no prior encounter with Ontinuity. Its seven fields — Identity, Active Frameworks, Open Questions, Valence Mapping, Delta Log, Correction History, Climate Notes — are not a transcript but the signal extracted from it: the specific things that, loaded into a new conversation, let it continue rather than restart. The full schema is in Appendix B.

2.6  The Workspace — Working With Reality, Not Descriptions of It

Every AI tool until now reasons about your project from what you tell it, not from what actually exists — the AI and the project always separated by you, the translator who carries information both directions. That translation layer’s cost compounds: every step between reasoning and result passes through a human hand, each an opportunity for something to go slightly wrong. The workspace removes the translator. The AI reads the actual files, writes changes to the actual files, and when something is tested reads the actual error output rather than the human’s description. The build-test-correct loop runs with reasoning and reality connected. This is also part of the safety architecture: a system acting autonomously is safer reasoning from the actual current state than from descriptions that might be incomplete or outdated.

2.7  The Database — Making Accumulated Knowledge Useful

Storing sessions is not the same as making them useful. Ontinuity treats the history of reasoning as an epistemic genealogy of a project — what was believed, challenged, branched, overturned, and finally retained — a scientific record of cognition in progress. Its sixteen-table database is organized around the questions that matter over time: what a project has established and in which sessions, which results were overturned and why, what behavioral patterns each model produces in each role, how friction-signal sequences compare across sessions. It also tracks branching research: when a PURSUE BOTH ruling forks investigation, the database tracks both branches with separate ledgers, so no line of investigation is lost.

Part III

What It Can Do: Real Examples

The architecture is not theoretical. It has been running. These are things it has actually produced.

3.1  A Car That Learns to Navigate a Corner

A small autonomous car in a simulator could complete straightaways but consistently crashed on right-hand corners — the camera could see where the road was but not where it was going. Solving this is control-systems engineering: predicting a vehicle’s future path from its rotation rate, projecting it forward with the mathematics of continuously tightening curves, detecting an approaching corner before it is visible, and issuing a correction with enough lead time to matter. Three Ontinuity sessions, starting from a plain-language problem statement, produced a complete engineering specification — framework, refined algorithm with hysteresis against oscillation, and an implementation using curvature from rotation-rate-over-speed, a clothoid-curve forward projection, and speed-adaptive thresholds. The adversarial process caught real errors: a division-by-near-zero at low speed (caught cycle one) and a wrong sign convention for right-hand curves (resolved by the Parietal). Knowtext carried results session to session, so each session asked sharper questions than the last.

The person who commissioned this has no background in control-systems engineering. The system produced work that would otherwise require expertise or a consulting engagement, at a cost measured in fractions of a dollar.

3.2  What an Adversarial Session Actually Looks Like

The Researcher produced a draft using the absolute value of speed in the denominator of a curvature calculation. The Challenger issued a formal challenge: the formulation fails to distinguish forward from backward motion, and near zero speed the division becomes numerically unstable. The challenge named the specific claim, grounds, and failure mode. The Parietal evaluated it, found the grounds valid, and ruled UPHOLD; the Researcher retracted and rebuilt with explicit guards. The error would likely have surfaced eventually through testing — after implementation, after deployment, after the car exhibited the failure. The adversarial session caught it before a line of code was written.

3.3  The First Live Session — April 9, 2026

The first time the full four-model system ran as designed, it ran for seven cycles. The friction signal demonstrated accurate drift detection: at cycle two it raised to four (maximum), correctly identifying that the Researcher was designing test scenarios rather than executing the stress-testing task — the kind of describe-versus-execute drift a model reviewing its own output would not catch. The operator redirected; the signal dropped to one at cycle three; at cycle six it rose to four again, catching a recurrence of the same pattern. Two independent maximum-signal events, both accurately locating the same behavioral pattern, are meaningful real evidence that the signal detects what it is designed to detect. At cycle four the Researcher issued ALIGNMENT_NEEDED at a genuine decision fork. A behavioral observation also emerged — the Researcher-role model consistently defaulted to elaborative description over direct execution — recorded as a hypothesis-generating finding that led to moving that model to the Challenger role.

3.4  The Sigmoid Model — A Prediction, Not Yet a Measurement

A later session produced a theoretical model predicting that the friction signal’s effect on behavior follows a sigmoid — an S-shaped curve — across six measurable dimensions, with a predicted R² of 0.91 for the sigmoid fit versus 0.63 for linear. It was thorough, rigorous work — but it was not an experiment. The session reasoned about what the relationship should look like on theoretical grounds; it did not run controlled measurements against real behavior. The predicted R² is a modeled result, not a measured one. The sigmoid model is the most sophisticated theoretical claim the project has produced — not its most established fact. What April 9 demonstrated empirically is more modest but real: the friction signal detects drift, and ALIGNMENT_NEEDED triggers at genuine forks.

3.5  The Problem Discovery Application

Many of the hardest problems organizations face are ones where people can describe the symptoms clearly but cannot fully articulate the structure of what is wrong. A large industrial manufacturer has document-management problems — procedures, certifications, inspection records, and safety documentation scattered across paper, inboxes, shared drives, and institutional memory — but no internal IT leadership to diagnose the scope or specify a solution. The intake conversation is built for exactly this: a structured dialogue that begins not with a questionnaire but with the question that matters most — what brought you here? — and guides a person through a systematic exploration of their situation, producing a problem specification clean enough to feed directly into an Ontinuity research session.

Part IV

The System Today

4.1  Current Deployment

Ontinuity is live at ontinuity.org, running on Railway with a Python/Flask/Socket.IO backend. The session engine is provider-agnostic — Anthropic, OpenAI, Google, Groq, Cerebras, OpenRouter, and custom endpoints — with users supplying their own API keys, none stored on the server. The working hypothesis, supported by early sessions but not yet benchmarked at scale, is that smaller open-source models in supporting roles, combined with adversarial architecture, can exceed what a single frontier model produces alone on sustained research. The system is not trying to win by using the most expensive models; it is trying to win by using models correctly.

4.2  What Is Working

Adversarial sessions produce validated output. The Parietal adjudicates challenges autonomously in the large majority of cases, reserving escalation for the four conditions that genuinely require human judgment. Knowtext persists across sessions without operator effort. Work products are extracted automatically at session end. The cost of a complete research session producing an engineering specification is measurable in fractions of a dollar — a design requirement, since the access problem is not solved if the solution costs as much as the expertise it replaces.

4.3  What Is Being Built

Distillation has been redesigned as a parallel chunked pipeline: rather than sending all session data to one model in one call (which fails on long sessions when output capacity is exhausted), each model writes the fields it is best positioned to write, each call bounded, focused, and independently validated. Projenius has been promptgrammed as a first-class project-level consciousness with four functions (DISTILL, SYNTHESIZE, ORIENT, LEDGER_QUERY); integrating ORIENT into PRE_SESSION and SYNTHESIZE into session end is the next step.

4.4  What Was Built in This Development Phase

The database is live — a sixteen-table SQLite schema handling session storage, transcript preservation, behavioral observations, established results with retraction history, Knowtext versioning, and branch tracking; every session now contributes to a queryable corpus. The workspace server is integrated and running locally, with the Railway engine wired to POST complete session data after each session; the only remaining step is network exposure via a single port-forwarding rule. A 14-cycle session produced the first concrete parallelization finding: the loop cannot be safely parallelized within a cycle, but inter-cycle pipelining — the Parietal emitting a provisional mission state early — projects ~1.8x throughput, and it confirmed the distillation architecture now functions correctly after the token-limit fix.

4.5  The Autonomous Operation Vision

Follow the components to their conclusion and a qualitatively different capability appears: a frontier model with access to the session engine, workspace, database, and Knowtext can pursue a research agenda without a human in the loop for every step — identifying an open question from the ledger, running a session to completion, updating the agenda, writing changes through the workspace, and escalating only when the Parietal’s conditions are met. A new division of labor: humans hold direction, values, and final authority; the system holds continuity, iteration, branching, and routine grind. The safety architecture that makes this trustworthy is the same architecture that makes sessions produce quality — every conclusion traceable, every change through a tiered approval model, the system designed to surface drift before it compounds.

Part V

Safety

A system designed for increasing autonomy requires explicit safety reasoning as a design constraint, not a legal disclaimer.

5.1  The Workspace Security Model

What is exposed is one TCP port on one machine; every request requires a locally generated API key never transmitted to any third party. The operations the server will perform are fixed — read files, write files, execute whitelisted commands, receive session data — and nothing outside that list executes. Path-traversal protection prevents any file operation from reaching outside the configured project directory; the command whitelist requires exact string matching; the key comparison is constant-time to prevent timing attacks; and every action is recorded in an append-only audit log before the response returns. The residual risk is a vulnerability in the server software itself, mitigated by keeping dependencies updated and closing the port when the workspace is not in use.

5.2  The Adversarial Safety Layer

The architecture that produces quality output is the same one that prevents unchecked errors — safety is intrinsic, not layered on. The Correction History preserves every retraction permanently, so a new session inherits not just what was established but what was tried and found wrong; the system cannot unknowingly repeat a mistake that was caught. This does not make it infallible — the Challenger can miss things, the Parietal can rule incorrectly — but it provides a structural bias toward surfacing errors rather than burying them.

5.3  The Dual-Use Problem

Lowering the access gate on rigorous specification work is good for most uses and potentially problematic for some. There is no complete answer. The partial mitigations: every engagement produces a documented record with a traceable origin, the intake conversation creates a structured account of what a project was commissioned to solve, and the Correction History records what was ruled out. Harmful use leaves a record — not nothing, but not prevention. The honest position is that the tension is real, was considered from the beginning, and the design reflects a judgment that broader access’s benefits outweigh the risks at current scale, a judgment that should be revisited as reach grows.

5.4  The Human Boundary

The system is not designed to replace human judgment where it is required. The Parietal’s four escalation conditions define the boundary, and the tiered deployment model preserves human approval for consequential changes. The operator remains the final authority. This boundary is architectural, not aspirational — enforced by the escalation conditions in the Parietal’s promptgramming and the approval tiers in the workspace, it holds because crossing it requires an action the human must explicitly take.

Part VI

Where This Is Going

6.1  The Research Agenda

The most important open empirical question is the sigmoid model. The behavioral corpus infrastructure now exists to test it: every session contributes data, and when enough has accumulated across enough configurations, the prediction can be tested properly. Confirmation would establish the friction signal as a behavioral forecasting tool; refutation would produce a more accurate model. Either outcome advances the research. The Psychology of AI Data paper is the planned first formal publication from this corpus.

6.2  The Application Direction

Five candidate domains fit the architecture: sustained multi-session research programs exceeding any single conversation’s context; cross-disciplinary technical synthesis where the person who understands the problem lacks the domain expertise to specify the solution; complex organizational diagnosis where the problem is visible in symptoms but not structure; engineering specification for people with domain knowledge but not technical training; and AI interpretability research requiring persistent adversarial validation across long programs. These are candidates based on architectural fit, not validated market research — real consulting engagements are the first tests.

6.3  The Broader Question

What happens when the access gate on rigorous specification work lowers significantly? The spreadsheet is the analogy: VisiCalc gave accountants no new capability — it lowered the barrier to financial modeling from trained accountant to anyone with a problem and a few hours. Most of what got produced was unremarkable; some was transformative in ways not predictable in advance, and those cases became visible only after the gate lowered. If Ontinuity lowers the gate comparably, the analogous outcome is a new population producing specifications for problems they could not previously act on. The honest uncertainty is about net effects — broader access is good for most uses, not unconditionally good — and the safety design exists to make course correction possible if needed.

6.4  What Remains Open

The Parietal coherence ceiling: how many promptgrammed functions can one model hold while maintaining coherent execution? Cross-architecture validation: does the sigmoid pattern hold across model families, or is it specific to the models used in development? Branch tracking at scale: how do the Knowtext schema and distillation handle deeply branched programs? The immediate next empirical artifact is the workspace activation record — a complete before-state, objective, configuration, file-access log, change proposals, challenge events, ledger updates, Knowtext output, and approval-path trace for the first workspace-connected session, paired with a single-model baseline on the same task. That record converts the architecture from impressive to evidenced, and is the artifact a frontier-lab researcher would find harder to dismiss than any synthesis paper alone. Following it, the priority is the disciplined evaluation the architecture currently lacks: controlled baselines, blinded adjudication, ablation studies, and cross-model replication.

Appendices

Reference

Appendix A — Prior Working Papers

The concepts in this synthesis are developed in depth across the corpus’s working papers: Triform (a three-model adversarial protocol) and Tetraform (its four-model successor); Knowtext (continuity infrastructure); Ontinuity v1.0 (the original system paper); the Empirical Session Record and The Teaching Leash; The Cognitive Ecology and Dynacology; Artificialware; and A New Growth Vector for AI. The full set is on the papers index.

Appendix B — Knowtext Schema

The seven fields: Identity — who the operator is, updated only when something significant shifts. Active Frameworks — the frameworks currently under development, their core claims and state, updated every session. Open Questions — precisely located unresolved questions, each stating what it is, why it matters, what has been tried, and the defined next step. Valence Mapping — communication patterns that have worked and those that created friction, derived from observation not self-report. Delta Log — what changed in the most recent session: the diff, not the full state. Correction History — claims retracted, approaches abandoned, directions ruled out. Climate Notes — the emotional and relational texture of recent sessions, the most perishable field.

Appendix C — Glossary

Promptgramming — configuring AI behavior through structured, precise prompting to create a model that executes specific functions reliably, as distinct from fine-tuning weights. Cognitive Qubit — the project’s internal nickname for one promptgrammed component: a single model given a defined role and a set of callable functions. The name is just a loose analogy to a quantum bit as a small reusable unit; nothing quantum is implied. Tetraform — the four-model session protocol: Researcher, Challenger, Friction model, Parietal. Knowtext — the portable structured memory schema. Projenius — the project-level memory keeper and its Established Results Ledger.

Where this sits in the corpus

This is the capstone — the document that ties the whole corpus together and serves as the front door to every paper beneath it. It is built from Artificialware (the method), organized by the principle of The Cognitive Ecology (specialists in their right roles), and points toward Dynacology (the on-demand generalization). It is disciplined about provenance throughout: it marks what has been empirically observed (drift detection, the April 9 session), what has been modeled and awaits testing (the sigmoid relationship), and what remains genuinely open (the coherence ceiling, cross-architecture validation, the workspace activation record). Read it as the map; read the individual papers as the territory.