The model brief
A professional model should carry the work, not only answer the prompt.
PRO v2 is being designed for assignments that unfold over time: a product with existing decisions, a repository with dependencies, a 3D scene with a real hierarchy or a connected application where every action has consequences.
01 · Why PRO v2
The difficult part of professional work often begins after the first answer.
The current SpectraMind AI Pro v1 is our strongest available model for demanding reasoning. It can analyse a difficult question, produce advanced code and work through complex material in depth. For many requests, that is exactly what a professional user needs.
But a technically convincing answer is not the same as a finished result. A change can be logically correct and still target the wrong file. A generated script can look complete while breaking an existing convention. A Blender automation can run successfully and still damage the scene hierarchy. The work becomes reliable only when the model understands the environment around the answer.
PRO v2 moves the product direction from answering a hard request to maintaining a dependable workflow. The intended model first identifies the relevant system, forms a scoped plan, uses an appropriate connected capability and stays with the task until there is evidence that the result works.
This is not an excuse to make every interaction slower or more complicated. Professional judgement also means recognising when a request is simple. Short questions should remain direct. Planning, tools and verification should appear only when they materially improve the result.
02 · How it should work
One objective, carried through a complete execution loop.
PRO v2 is being shaped around a persistent task state rather than a sequence of disconnected replies. The model should know what the user asked for, what it discovered, which decisions were made, what changed and what remains uncertain.
Understand the environment
Inspect the relevant files, dependencies, application state, project conventions and constraints before proposing changes.
Form a scoped plan
Separate assumptions from confirmed facts, identify risk points and make the intended outcome explicit.
Act through the right capability
Use code, research or a supported application only when it is needed, with access limited to the active task.
Verify the real result
Read build output, run tests, inspect a preview or compare scene state instead of treating generation as completion.
Leave a clear handoff
Explain what changed, what was validated, what remains open and how another person can continue the work.
The model should be able to recover when a check fails. A failed build is not the end of the workflow and should not be hidden behind a confident summary. It becomes new evidence: the plan is updated, the failure is traced and the next safe action is selected.
03 · Evaluation plan
We will measure completed work, not only impressive responses.
PRO v2 has not been released and we are not publishing benchmark claims for it today. Before presenting performance results, we want evaluations that resemble the work the product is meant to handle. Those evaluations need to test the complete path from initial request to verified outcome.
Does the model find the correct implementation path, preserve conventions and avoid unrelated regressions?
Can it maintain requirements, decisions and unresolved questions across a longer sequence of work?
Does it select the right capability, request confirmation at the right moment and avoid unnecessary actions?
When a test or action fails, can the model diagnose the evidence and continue without restarting blindly?
Can it change a scene while respecting hierarchy, scale, naming and non-destructive production practices?
Does the workflow produce a stronger result without using excessive context, unnecessary tool calls or repeated work?
When the evaluation suite and model behaviour are stable enough to be meaningful, we intend to publish results together with methodology, limitations and the configurations used. Until then, the capabilities on this page remain product direction rather than measured release claims.
04 · Safety and control
More agency requires clearer boundaries.
A model that can work with repositories and professional applications needs stronger product controls than a model that only returns text. PRO v2 is being designed around scoped access, visible intent and review gates for sensitive or irreversible actions.
The objective is not to interrupt normal work with constant confirmation prompts. Low-risk, reversible activity should remain fluid. Confirmation should appear where the consequence justifies it: sending information externally, changing protected resources, executing a destructive operation or extending access beyond the active task.
Connected work should begin with the smallest useful set of files, data and application permissions.
The model should describe material changes and separate a proposal from an executed action.
Sensitive steps remain behind explicit approval instead of being hidden inside an automated chain.
Outputs, failures and checks should be visible enough for a user to understand what actually happened.
These controls are still part of the development work. Their exact behaviour may vary by application, plan and risk level as the preview evolves.