Skip to content
Saor R&D Research Library

TPMS — Engineering Continuity & Verification

The question

Section titled “The question”

How can engineering knowledge, decisions, uncertainty, and supporting evidence remain useful as development moves between people, agents, and working sessions?

Why TPMS exists

Section titled “Why TPMS exists”

Engineering work leaves behind source code, configuration, tests, diagrams, issues, and other records. These artifacts are valuable, but they do not automatically preserve the reasoning that made a decision sensible.

A later engineer may be able to see what changed without knowing which question the change answered, which alternatives were rejected, what constraints shaped the choice, or how much uncertainty remained. A test may have passed for one version, input, environment, and set of conditions, while the system around it has since changed. The result is still an observation about its original run, but it may no longer support the same decision.

This is an engineering continuity problem. It appears when work moves between people, development sessions, tools, or AI-assisted processes. The challenge is not to preserve every intermediate thought. It is to preserve enough context for a later person to understand a decision, examine its evidence, and judge whether the reasoning still applies.

Why Engineering Decisions Need Evidence explores this problem through decision provenance, evidence applicability, handoffs, and the different levels of assurance provided by self-review, separate evaluation, and independent verification.

The approach

Section titled “The approach”

TPMS is an experimental, provider-neutral, project-side advisory engineering control plane for AI-assisted software engineering.

At a high level, its research direction explores how the information around implementation can remain visible as work changes. That includes the question being answered, the decision made, the uncertainty that remains, the evidence available, and the conditions that would make the decision worth revisiting.

The phrase control plane describes the area of concern rather than a promise of automatic enforcement. TPMS explores ways to support engineering coordination, preserve useful context, track uncertainty, and make the relationship between decisions and evidence easier to examine. It supports engineering work rather than replacing engineers or coding agents. The engineering agent or human engineer remains responsible for solving the technical problem.

Advisory guidance is not the same as system-level enforcement. TPMS is not a replacement for engineering judgment, independent review, or an operating-system sandbox.

From concept to experimental implementation

Section titled “From concept to experimental implementation”

TPMS has progressed beyond a purely conceptual stage into experimental development phases that include implemented advisory control-plane components and recorded verification at specific historical baselines. That work has examined practical concerns such as repository orientation, context routing, verification evidence, continuation between sessions, and handoff records.

Those records are bounded by the version, conditions, and questions that were tested. They do not establish a finished product, universal reliability, or production readiness. Historical results also do not automatically apply to the current development checkout after later source changes.

TPMS remains developmental. The public account distinguishes what has been implemented, what has been tested, what has been independently evaluated, and what remains a research question.

Research challenges

Section titled “Research challenges”

Selective continuity

Section titled “Selective continuity”

An engineering record can fail by being too small to explain a decision or too large to remain useful. A central challenge is finding the smallest useful account of the question, decision, assumptions, uncertainty, and evidence without turning ordinary work into an archive of every thought.

Decision provenance

Section titled “Decision provenance”

A decision is easier to revisit when its origin is visible: the requirement or question that prompted it, the alternatives considered, the constraints involved, the evidence supporting it, and the changes that might invalidate its original reasoning.

Evidence applicability

Section titled “Evidence applicability”

“The test passed” and “the test is still evidence for this decision” are different statements. The second requires attention to the version under test, relevant inputs, environment, intended scope, and changes made since the evidence was collected.

Handoffs across people and tools

Section titled “Handoffs across people and tools”

Handoffs often compress the information that later judgment needs. This becomes especially important when work crosses development sessions or moves between human engineers and AI-assisted tools. A useful handoff should help the next person distinguish an observation from an assumption and a current fact from an inherited claim.

Proportionate verification

Section titled “Proportionate verification”

Self-review, separately performed evaluation, and independent verification provide different levels of assurance. The appropriate level depends on risk. A later review by the original builder remains self-review; independent verification requires sufficient separation from the original work and assumptions to challenge the claim and its conditions.

Human-directed engineering

Section titled “Human-directed engineering”

AI tools can expand the range and speed of investigation, but responsibility for engineering decisions, acceptable risk, and final acceptance remains human. A continuity system should support that responsibility without hiding uncertainty behind a polished output or treating advisory guidance as enforcement.

Open questions

Section titled “Open questions”
  • What is the smallest useful record that lets a future engineer recover the meaning of a decision without preserving every intermediate thought?
  • How should a reviewer determine whether evidence still applies after the source, input, dependency, or operating context changes?
  • How can uncertainty remain visible across handoffs without making engineering work unnecessarily complex?
  • What can an advisory control plane support, and where must external tools or independent processes provide enforcement and verification?
  • How should review effort be proportionate to risk while still challenging the assumptions behind a result?

TPMS sits within Saor R&D’s broader interest in understandable, verifiable, and user-controlled systems. Its public research direction is deliberately open about uncertainty: a useful engineering system should make it easier to see what is known, what is assumed, and what still needs to be tested.

Section titled “Related reading”