Goal & context
What the work is trying to accomplish, which identity and context apply, and what must remain in scope.
NAESTRO / ARCHITECTURE
A trajectory is work with memory, policy and a next move.
NAESTRO is the META BRAIN coordinating goals, intelligence, memory, tools, execution and review. A trajectory is the inspectable path from an intent to an outcome, including pauses, refusals and recovery.
People, intelligence and tools
Connect applications, model systems, CLIs and business services.
The MIND ecosystem
Contract, execution, memory, routing, governance and evidence retain distinct roles.
Specialized workspaces
Engineering, research and business modules develop in stages.
The public model
One model response can produce useful text. A continuing operating environment has to hold the thread: what was requested, what was tried, what a tool returned, what policy allowed and what should happen next. NAESTRO provides that coordination layer around the systems that do the work.
Planning
A continuation-aware plan turns intent into bounded work, with a next action and a reason for choosing it.
Tools & providers
Connectors perform the requested work through declared interfaces. Availability and provider limits remain visible.
Policy
Rules, approvals and refusals sit at the decision boundary before consequential work is applied.
State
Memory and runtime state carry the work forward while preserving the distinction between observed and inferred context.
Evaluation & evidence
Reviewers can inspect what happened, what was missing and which claims the record actually supports.
A commercial product, from workspace to edge
NAESTRO is a proprietary commercial product of STARGA, Inc. Its product architecture is designed to bring together a workspace frontend for projects, conversations and tools, and an administration frontend for organizations, access, providers, modules, nodes and audit review.
Edge deployment is central to the direction: keep useful execution and context close to the work, with configured connections to private fleets and cloud services. Each deployment defines its data boundary, admitted capabilities and external dependencies.
Explore the product architectureImprovement has its own trajectory
The self-evolution direction applies the same discipline to changes in plans, skills, memory and routing. Preserve the baseline, propose a change, evaluate it against an agreed objective, then decide whether the evidence supports adoption.
- 01
Baseline
Keep the current version and the outcome to improve.
- 02
Proposal
Make a bounded change with an explicit hypothesis.
- 03
Evaluation
Compare results, costs and required checks.
- 04
Decision
Adopt an authorized improvement or retain the baseline.
Failed candidates and inconclusive results remain useful evidence. The integration roadmap connects these records to independent review; an improved score alone does not authorize changing the operating system.
See the first evaluation protocolBoundaries that stay visible
Runtime work
Agents, providers and connectors may be substituted according to the workflow. NAESTRO describes the handoff and records the relevant result; it does not imply that every provider supports every mode.
Governed decisions
A policy decision is part of the trajectory. A refusal, unavailable tool or missing approval is a meaningful state that can be resumed once its condition is met.
- 01
Contract
MIND-IntentTurn intent into an explicit semantic contract: the requested outcome, constraints and acceptance conditions.Inspect boundary - 02
Proposal
Models · humans · optimizersProduce a candidate source program, IR, kernel or device plan. A proposal carries no execution authority.Inspect boundary - 03
Establishment
MINDNormalize, type-check and apply the supported verification procedure. Rejected or unresolved candidates return for revision.- Established
- Rejected
- Unresolved
- 04
Authorization
512-MINDEvaluate the applicable invariants, governance and policy. A refused action does not proceed to execution.- Authorized
- Refused(code)
- 05
Execution
mindc · admitted substrate · bounded deviceLower the admitted computation for a supported target and execute within the authorized scope.Inspect boundary - 06
Evidence
Evidence interfacesConnect the canonical artifact, establishment evidence, authority decision and execution receipts for review.Inspect boundary
Establishment checks supported semantics. Authorization determines what may proceed. Evidence preserves the decision and outcome.
From contract to action
The admission model below separates component responsibility from integration maturity. It describes which layer owns a decision; it does not claim that every handoff is implemented in every deployment.
- MIND-Intent
Define the contract
Turn intent into an explicit semantic contract: the requested outcome, constraints and acceptance conditions.
- Models · humans · optimizers
Propose an implementation
Produce a candidate source program, IR, kernel or device plan. A proposal carries no execution authority.
- MIND
Establish what can be checked
Normalize, type-check and apply the supported verification procedure. Rejected or unresolved candidates return for revision.
- Established
- Rejected
- Unresolved
- mindc · admitted substrate · bounded device
Lower and execute
Lower the admitted computation for a supported target and execute within the authorized scope.
- Evidence interfaces
Retain artifacts and evidence
Connect the canonical artifact, establishment evidence, authority decision and execution receipts for review.
This is the ecosystem’s responsibility model. Each implementation and integration has a defined scope; establishment does not grant authority or imply proof of every property.
MIND-Intent: define the contract
MIND-Intent’s design takes a human goal and constraints through a reviewable IntentSpec to a Contract IR trust boundary. The current work defines that contract architecture and reference examples; parser, analyzer and end-to-end implementation remain planned.
See the MIND-Intent roleMIND establishes; 512-MIND authorizes
MIND normalizes a proposed computation and checks its supported semantic obligations. 512-MIND applies the separate invariants, governance and policy decision for an admitted action. Authorization does not replace semantic establishment or imply runtime proof.
See the 512-MIND roleA rejected or unresolved contract has no execution path. Arch-MIND contributes structural review of boundaries and relationships; structural review is distinct from semantic proof and runtime execution.
A substrate roadmap with explicit uncertainty
The substrate roadmap spans CPUs, GPUs and other accelerators, FPGA/ASIC, quantum and neuromorphic systems. Admission requires a concrete target contract, supported semantics and relevant verification evidence. Quantum measurement uses an explicit statistical contract; physical observations retain explicit uncertainty. Coverage is demonstrated per target and workload as adapters mature.
Failure is a state, not a footnote
The explorer on the home page uses a deliberately small example: a plan reaches a refused action, names the missing evidence, then resumes. The example is illustrative. It shows the shape of reviewable work without claiming universal enforcement across arbitrary systems.
See how we evaluate a trajectoryBring a real workflow. Start with a bounded question.
Discuss an evaluation