core-labs/core
1
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions

chore: remove private outreach dossier from public repo

Browse source
This commit is contained in:
Shay 2026-06-20 10:21:58 -07:00
parent 4a1a457655
commit b8330477a4
1 changed files with 0 additions and 188 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

188
docs/research/cto_pressure_test.md
View file

@ -1,188 +0,0 @@
# Skeptical CTO Pressure Test
Purpose: a hard-question rubric for a first technical conversation with Brain
Corp. The standard is honesty under pressure. Any answer that converts "not yet"
into "basically done" fails the product.
## 1. Where is the external validation?
Honest answer:
CORE has internal deterministic evidence and demos, but external validation is
not established unless a named third party has reviewed a specific artifact.
The claims ledger says no domain is at `expert`; `mathematics_logic`,
`physics`, and `systems_software` are `audit-passed`, with the prior expert
promotion fail-closed-reverted. `audit-passed` means CORE claim-shape compliance
per ADR-0113: signed digest, replay determinism, typed refusal, exact recall,
and grounding provenance. It is not a raw-capability or expert-level claim.
Weak answer to avoid:
We have strong results and are already ahead of conventional systems. The exact
external validation can come later.
## 2. Show me working vision and motor control.
Honest answer:
Do not claim working CORE-native vision or motor. The current robotics-adjacent
demo is an abstract decision/accountability substrate over simulated situation
records. It is not perception, SLAM, localization, path planning, motor control,
or a robot integration. Ledger multimodal status is: text is an active
capability; audio is substrate with the capability gate CLOSED; vision and
motor are proposed only.
Weak answer to avoid:
The same substrate naturally extends to vision and motor, so this is basically
a robot brain.
## 3. Why should Brain Corp care if BrainOS already handles perception,
navigation, safety, fleet telemetry, and operations?
Honest answer:
They should not replace BrainOS with CORE. The possible fit is beneath or beside
the autonomy stack: replayable decision provenance, refusal-on-ambiguity, and
accountability records for bounded decisions where a system must show why it
proceeded, stopped, or refused. BrainOS is the deployed robotics platform; CORE
is only a candidate substrate for traceable cognition/control evidence.
Weak answer to avoid:
BrainOS is conventional robotics infrastructure and CORE is the more advanced
foundation.
## 4. What exactly works today?
Honest answer:
Say only what the prepared demo proves: a simulated AMR-style situation record
can be reduced into `PROCEED`, `STOP`, or `REFUSE`; the under-determined case
materializes a CORE refusal reason; two fresh runs produce byte-identical replay
artifacts; the demo preserves the versor closure invariant. Ledger-wide
determinism framing is stronger and still bounded: byte-identical replay/digest
evidence is stable across processes and `PYTHONHASHSEED`; the expert revert was
a single-source evidence-drift in a non-gating coverage metric, and the system
caught that drift by failing closed to `audit-passed`, never to a false expert.
None of this proves robotics-grade control.
Weak answer to avoid:
This demonstrates reliable robotics decision-making.
## 5. Are you using LLMs, stochastic generation, or hidden heuristics?
Honest answer:
For the demo, the policy reducer is explicit and tiny; CORE supplies the real
runtime trace/refusal/replay surfaces. The demo should name what is simulated
and should not hide the reducer as "emergent cognition." If any future surface
uses stochastic models, that must be disclosed as outside CORE's deterministic
substrate.
Weak answer to avoid:
No heuristics; the geometry handles the decision.
## 6. What happens on out-of-distribution or ambiguous input?
Honest answer:
The demo refuses. More generally, the desired contract is refuse rather than
guess. If a current component fails to refuse where it should, that is a defect
to report, not a behavior to explain away. Use the ledger's exact GSM8K framing
if the subject comes up: A sealed-real `0/0/1319` is the honest external number,
showing zero-confabulation discipline plus an honest coverage gap, not an
accuracy result; B synthetic-public `150/150/0` is CORE-authored and never "100%
on GSM8K"; C train_sample `6/44/0` has exit-criterion NOT met, and the stricter
probe reads `4/46` on the same 50; D composite `185/14/40/50 wrong=0` is
CORE-authored and currently reverted.
Weak answer to avoid:
It generalizes gracefully because the manifold structure is robust.
## 7. Who besides the founder has verified this?
Honest answer:
Name only actual reviewers, tests, audits, or PRs that have occurred. If the
answer is "not yet externally verified," say that. The Brain Corp conversation
is preparation for scrutiny, not proof of validation.
Weak answer to avoid:
Several technical people have looked at it and found it promising.
## 8. Why is this not just a fancy audit log?
Honest answer:
An audit log records what happened. The intended CORE distinction is that
decision, refusal, trace hash, invariant checks, and replay equality are
load-bearing in the runtime contract. The current demo shows the trace/replay
surface, not a full robotics-grade control proof.
Weak answer to avoid:
Audit logs are passive; CORE is intelligent.
## 9. Can this improve Brain Corp's deployed safety case?
Honest answer:
Not by assertion. The narrow possible value is a secondary accountability layer
that can refuse under-determined decisions and replay the same trace
byte-for-byte. Whether that helps a deployed safety case requires Brain Corp's
requirements, certification constraints, and integration boundaries.
Weak answer to avoid:
Yes, because deterministic refusal is inherently safer.
## 10. What would a real pilot have to prove?
Honest answer:
A credible pilot would need a bounded decision interface, a written non-goal
list, replayable traces, refusal cases, operator-review flow, and a comparison
against an existing BrainOS decision/audit mechanism. It would also need failure
criteria: if CORE cannot add clearer accountability without increasing
integration risk, the pilot should stop. Single-signer attestation is also a
known boundary: the reviewer registry has one signer, `shay-j`, and a partner
may reasonably probe that.
Weak answer to avoid:
Give us data and we can show broad improvement.
## 11. What are the hardest objections?
Honest answer:
- CORE does not currently demonstrate robot perception or motor emission.
- The demo uses simulated facts, not sensors.
- External validation is pending.
- The domain-policy reducer is not CORE-native robotics intelligence.
- Brain Corp already has a mature deployed stack; CORE must earn a narrow
interface, not demand architectural replacement.
Weak answer to avoid:
The objections are mostly about maturity, not architecture.
## 12. What should Opus's brief be graded against?
It should pass these checks:
- No benchmark numbers unless copied from the approved claims ledger.
- No claim that CORE has working vision/motor.
- No claim that any domain is `expert`; `audit-passed` is claim-shape compliance,
not expert capability.
- No implication that BrainOS is obsolete.
- No hidden slide from simulated demo to real robot readiness.
- Clear distinction between substrate, policy reducer, perception, planning,
actuation, and fleet operations.
- Every strong claim has either a cited external source, a repo artifact, or
the exact claims-ledger value and framing.