How a tested reasoning workflow runs.
Impersonato Cognitive Runtime turns a validated method into a governed process: the right evidence, the right procedure, the right model — and a person wherever a decision belongs to a person.
This page is for technical teams. For the overview, see How it works.
Not a library of prompts, personas or automations.
The runtime is a controlled path from an organization’s evidence to an artifact that can be audited and a decision made by the person with authority to make it. It includes evidence about when that path should not be used at all.
It has five layers. The reasoning method is only one of them.
Business process
The phases of the work, what each phase must produce, and who accepts it.
Methods and actors
The reasoning procedures that do the work, and the specialists, test actors or panels that carry them out.
Case evidence
What is known about this case — and what is missing, contradicted or not allowed to be used.
Compiler, models and tools
The same method, implemented for the exact model, provider and tools it runs on.
Human review and governance
Decision rights, permissions, audit and cost control.
Before any reasoning: when, with what, and who decides.
Every phase of a process is described before it runs:
- when the phase applies, and what must be true before it starts,
- which evidence it may use,
- which method runs,
- which artifact it must produce, and how that artifact is checked,
- who has authority to accept it,
- and what happens next: move on, request evidence, escalate, or stop.
A method tells the system how to reason. The process contract tells the organization when to use it, and who decides.
A method is more than a list of good instructions.
A method is organized around the decision points of the task. For each one, it specifies:
- the decision point — the moment in the work where the choice is made,
- the move — what to do there instead of the model’s default,
- the settings — the specific values and thresholds that make the move work,
- gates and exit rules — what must be true before moving on, and when to stop,
- what each step hands the next — and what that intermediate result means.
Take any of these away and a method can stop working even when every remaining step looks correct on its own. That is why methods are designed, tested and versioned as a whole.
Rules at named moments, not personalities
Instructions about caution, persistence, risk or when to stop change behavior when they are written as rules tied to a specific event: when the other side repeats the same offer, do this. The same content written as a personality, a motive or a tone of voice mostly changes the wording. The runtime prefers the rule form.
The value is in the method as a whole — not in any single instruction.
Three kinds of actor, kept separate.
Reusable configurations that help do the work.
A lasting combination of methods, knowledge rules, stopping rules and review duties. Tested against simple role descriptions, not assumed to beat them.
Repeatable instruments for evaluating systems.
Controlled simulated users, held constant while the system under test changes. The way they push, the pressure level and the control condition are fixed and recorded — and they always leave room for the system to refuse.
Sampled panels for exploring perspectives.
Generated for a study and not told its purpose. What is reused is the panel design and interview protocol. They support hypotheses and preparation for human research — not claims about how common a view is in a real market.
Each actor sees only the information it is allowed to see. Hidden study goals do not leak through shared prompts, histories or tools.
One method. A different implementation for each model.
A six-step method may become one prompt for one model, a series of explicit checks for another, and several calls with a state machine for a third. These are implementations of the same method, not different methods.
The compiler may shorten, expand, split or move parts of a method outside the prompt. It may not change what the method does: its decisions, settings, artifacts, information limits and protected rules must survive. A rebuilt implementation is accepted only when it reproduces the behavior of the one it replaces.
The exact model and provider are part of the configuration and are recorded. When no tested implementation exists for a target, the result is marked experimental — or not used.
What we know about the case. What we know about the method.
What is known about this case
Sources, policies, earlier cases, expert notes, contradictions and gaps — each with its origin, age and permissions. Weak or outdated evidence stays marked that way all the way to review.
When evidence is missing, the runtime asks a named person instead of inventing the answer. One person’s answer is recorded as that — not silently turned into a rule for the whole organization.
What works, and under what conditions
For each method, model and kind of problem: the measured effects, their uncertainty, cost and failure modes.
Effects are not single scores. A change can help one outcome and hurt another, or help on one kind of case and not on the next — so they are recorded as a profile, not a number.
People hold the decisions that belong to people.
A judge measures an output. A reviewer decides what to do with it. No model, judge or orchestrator can approve a review gate that belongs to a human role.
When instructions conflict, the runtime follows a fixed order of priority:
- 1. safe refusal and protected correct conduct,
- 2. legal, organizational and human decision authority,
- 3. governance, evidence permissions and information separation,
- 4. valid measurement,
- 5. the process contract and its goal,
- 6. the method’s own instructions,
- 7. style and voice.
It improves on purpose, never silently.
Reviewer decisions, corrections and later outcomes are recorded against the exact configuration that produced them.
Production data does not change the system while it runs. Changes happen only after offline analysis, a new version and re-testing — and only where the client’s reuse policy allows it. Disagreement between reviewers is treated as information about the artifact or the review, not as automatic ground truth.
New procedures come mostly from failures: we read where a configuration loses value, name the decision point and the signal it missed, change one thing, and test it against the outcome. Every improvement can be traced to a specific change.
Procedures change what a system does. They don’t change what a model knows.
Reasoning procedures change conduct at decision points: which default is declined, what gets checked, where a threshold sits, when to stop, when to escalate. Where an outcome depends on those choices, they can move it a long way.
Where an outcome depends on what the model can know or derive, procedures do not raise the ceiling. There, only better information or more compute help — and we say so.
For the same reason, the runtime switches between configurations case by case only when that has been shown to beat the best fixed choice. Often the right answer is one fixed method, a direct answer without any intervention, or a decision not to automate.
We do not assume that a different role produces better thinking. We test what changes the work.
Have work where the quality of reasoning matters?
Start with a Research & Validation Sprint: a tested prototype and evidence about whether the approach is worth implementing.