How TOP works

00 / Analogy glossary

One translation layer.

The transport analogy ends with this table. The sections after it use literal system language.

01 / System boundary

TOP surrounds the model.

TOP does not train the foundation models. The proposed system sits between a business, its authorised data, its people, and the AI services it chooses to use.

Current boundary: this is the intended architecture. The surrounding production system has not yet been built or validated.

02 / TopOS

Local business infrastructure.

TopOS is proposed as a desktop application and centralised data hub for controlling how AI agents interact with a business.

• IdentityRegister people, agents, models and services so every actor has an explicit role.
• PermissionsApply least-privilege access to data, tools and actions, with human approval where required.
• ContextProvide authorised business information without making the entire company data estate available to every task.
• CommunicationDefine structured messages between agents and systems, including provenance and expected responses.
• AuditRecord what was requested, which systems were used, what was returned and whether the result passed its checks.

TopOS is not yet built, shipped or validated. Privacy and security requirements must be tested against the actual implementation, not inferred from this design.

03 / Icarus

Estimate before execution.

Icarus is the proposed forecasting layer for estimating token use and its API-rate equivalent before an AI job begins.

• InputsA bounded task description, selected model information and earlier comparable work where suitable data exists.
• OutputA range rather than a guaranteed point value, with a refusal when the available evidence is insufficient.
• EvaluationFreeze the estimate before execution, pair it with the measured result and test calibration prospectively.
• LimitationA runnable internal v1 exists, but reliable public pre-run forecasting has not been demonstrated.

04 / Daedalus

Select execution against explicit constraints.

Daedalus is a proposed selection layer for deciding which model, modality or combination should attempt a defined unit of work.

• Task contractRequired output, quality threshold, latency, privacy boundary and permitted providers.
• CandidatesAvailable models and tools described by capability, price basis and operating constraints.
• SelectionChoose a candidate only when it satisfies the task contract, with an escalation path for uncertain cases.
• EvidenceCompare decisions against measured cost and accepted output quality without treating an illustrative scenario as a result.

Daedalus has not shipped or been benchmarked. TOP has not demonstrated a general cost or quality improvement from this layer.

05 / Athena

Plan, supervise and verify completion.

Athena is proposed as an interactive planning and supervision layer for multi-step AI work.

• GoalTranslate the requested outcome into explicit completion criteria and constraints.
• PlanBreak work into bounded steps, dependencies, checkpoints and approval gates.
• MonitorTrack progress, repeated actions, deviations and evidence returned by each step.
• StopFinish when the completion criteria are met, or escalate when progress is unsafe, circular or unsupported.

Athena has not shipped or been benchmarked. Its planning and supervision approach remains a research direction.

06 / Privacy and security

Separate the verified boundary from the intended one.

Privacy and security claims must follow the implementation. The live analyser and the proposed TopOS system therefore have different evidence boundaries.

TOP aims to hand control of data back to the people using the system. Reaching that goal requires implementation evidence, security testing and continued scrutiny.

07 / Product status

What exists, and what does not.