Start by defining what can be checked
Pino SI’s public research snapshot includes STEM and a planned formal-math specialist. This article is a Kooya-authored explanation of our research direction, not outside validation. The SI ambition concerns superintelligence over the long term; neither that ambition nor a planning target establishes a capability today.[1]
The phrase verifiable reasoning can hide several different tasks. A calculation can have a known answer. A scientific explanation may require judgment about evidence and assumptions. A formal proof can be checked within a specified logical system. Treating these as one score would obscure the reasons a model succeeds or fails.
Mathematical answers and explanations are separate evidence
The MATH paper introduced a collection of competition mathematics problems with worked solutions. It provides a research example of evaluating mathematical problem solving rather than relying on fluent prose. We cite it for that distinction; this article does not identify it as Pino SI training or evaluation material.[2]
In a proposed evaluation, the final answer and the written justification could be reviewed separately. A correct number can arise despite an invalid intermediate step. Conversely, an otherwise sensible derivation can contain an arithmetic error. A report that records both gives a clearer view of what needs improvement than a collection of impressive-looking solutions.
Scientific reasoning must preserve the conditions
GPQA’s original research used expert-written questions in biology, physics and chemistry and examined the difficulty of answering them reliably. It illustrates why specialist judgment matters when assessing scientific answers. Its findings belong to that study and should not be converted into claims about Pino SI.[3]
For an illustrative physics task, the answer may depend on a stated approximation or boundary condition. An explanation that silently changes those conditions can become persuasive but irrelevant. A proposed assessment should ask whether the response uses the supplied information, distinguishes assumptions from observations and recognizes when the question leaves something unresolved.
Formal verification adds a different kind of check
LeanDojo introduced tools and research infrastructure for interacting with the Lean proof environment, alongside work on retrieving relevant premises. It is an example of research in which theorem proving involves an explicit formal environment. Citing it does not announce a Pino SI tool choice or establish that our planned specialist already proves theorems.[4]
For any future proof experiment, the claim would need to specify the statement checked, the permitted assumptions and the verification conditions. Acceptance by a checker concerns that formal task. It does not automatically show that the statement accurately represents a user’s original question or that every surrounding natural-language explanation is correct.
Check the translation into the formal task
Consider a request to establish a property for every allowed input. A formal statement could accidentally narrow the allowed inputs until the proof becomes easier. A successful verification would then answer the narrower statement. The relationship between the user’s request and the formal specification therefore deserves its own review.
This is particularly relevant to a project concerned with Philippine languages. The meaning must survive the journey from a naturally phrased question to symbols, definitions and assumptions. Kooya’s proposed evaluation lens is to inspect that transition explicitly. It is a methodological consideration for future work, not a claim that a language-to-proof pipeline has already been built.
Report the help the system received
A numerical answer obtained with a calculator, a scientific answer supported by supplied references and a formal proof completed after many search attempts are different experimental conditions. None is inherently invalid, but a report should state which assistance was available. Otherwise readers cannot tell what the result demonstrates.
Future assessments could separate an unaided response from a tool-assisted workflow and record time or attempt limits. They should also distinguish corrections supplied by an evaluator from work produced independently. These are possible reporting choices, not a finalized Pino SI protocol. Their purpose is to make a result interpretable and reproducible at the appropriate level of disclosure.
The same reporting issue appears in the planned coding pilot, where attempts, test feedback and execution conditions can change the result.
A specialist plan still needs narrow evidence
A specialist model can have a focused purpose without warranting a broad claim about scientific intelligence. The first useful result might concern a small, clearly defined family of tasks. The limits should travel with the result: task coverage, failure categories, allowed tools and the circumstances in which the system should defer.
Pino SI’s public direction leaves room to pursue this evidence in stages. A future STEM report should make it possible to see what was checked, what remains a proposal and what the result cannot support. Parameter targets and data quantities are planning information; they cannot substitute for successful evaluation of the particular reasoning skill under discussion.