Research / Questions that can fail
The system can work and the conclusion can still be wrong.
Velorin studies the points where memory, evaluation, authorization, and computational evidence stop being trustworthy. Each program is tied to a concrete failure and a decision the evidence must support.
01 / Persistent systems
Memory must be correctable.
A system that remembers across sessions can become more useful. It can also preserve mistakes, revoked information, and unsupported conclusions.
What we are testing
Whether useful continuity can coexist with explicit permission, visible sources, correction, contradiction, and revocation.
What the evidence changed
A tested adaptive mechanism did not establish superiority over simpler alternatives. Current designs favor source-backed records and explicit correction precedence.
What remains unresolved
Reliable governed continuity across live sessions. Private development is not a public product or release claim.
02 / Evaluation
The test can fail even when the system passes.
A reproducible score is useful only if the evaluator measures the behavior that matters and preserves the evidence needed to inspect the decision.
What we are testing
Whether VCE adds a distinct decision or evidence record beyond established evaluation infrastructure.
What we already know
The frozen decisions can be reproduced inside an existing framework. That proves compatibility, not added value.
Decision rule
Keep the smallest component that produces a reproducible difference. Otherwise retire the custom runner.
03 / Computational discovery
Evidence must survive the search process.
A mathematical answer is not trustworthy if the verifier, execution boundary, or resource record can misstate how it was produced.
What failed
A harness could certify terminal execution evidence while its container remained running.
What changed
No scored search, paid computation, or discovery claim proceeds on the affected path.
Next gate
Repair termination evidence, reproduce the repair independently, and restore deterministic CI.
04 / Authorization
More capability is not more authority.
A system may remember more, reason better, or coordinate more effectively. None of those changes silently enlarge its mandate.
Working rule
Knowledge, capability, and permission remain separate. Consequential authority must be explicit, attributable, and revocable.
Why it matters
A useful system should be able to challenge a decision without taking over the decision that belongs to a person.
Evidence status
This is a cross-program design requirement, not a claim that the wider governance problem has been solved.
Public record
Findings, failures, and stop decisions remain inspectable.
The project register shows what is active, completed, blocked, stopped, and archived. The publication index preserves the technical record beneath these plain-language conclusions.