Grab an individual skill, the full bundle, or the infographic — then drop the skills into your team's .claude/skills to standardize the workflow.
The gap between a script and a system
The first version of the RACap-POC was ten Python pipelines and ten SQL queries. Each one did real work: a LlamaIndex extractor turning trial readouts into a Neo4j landscape graph, a PySpark detector flagging commercial-volume anomalies, a Monte Carlo engine stress-testing royalty step-downs. Good scripts. But a script is a private asset — it lives in one analyst's repo, encodes its governance in that analyst's head, and breaks the moment someone else runs it without the institutional context baked in.
The second version is the interesting one. Each pipeline is re-expressed as a Claude Code skill — a SKILL.md folder with a triggering description, the workflow, the known failure modes, and, critically, the orchestration mechanism baked in. The governance travels inside the artifact instead of living as tribal knowledge.
Scripts encode what to compute. Skills encode how the firm computes it safely.
Ten skills, paired one-to-one
Each skill maps to exactly one pipeline, and each one carries a distinct piece of the Claude Code harness. Nine distinct orchestration mechanisms across ten skills — that variety is deliberate.
Skill
Pipeline
What it encodes
biomedical-kg-extractor
PY-01
MCP schema resolution + autonomous traceback repair for the Neo4j graph
three-signal-market-scraper
PY-02
/background polling + daily /compact so long jobs never overflow context
dashboard-api-automator
PY-03
Pre/PostToolUse hooks gating every write to the FastAPI layer
/batch decomposition, one worker per therapeutic area
structured-capital-monte-carlo
PY-06
/model switching — deep reasoning for stochastic logic, fast models for boilerplate
translational-grant-parser
PY-07
Packaged as a firm-wide /parse-grants skill
soc-price-compression
PY-08
CLAUDE.md pricing-rubric injection for house-consistent erosion curves
planetary-health-lca-parser
PY-09
PostToolUse hook enforcing the ESG taxonomy
dtcp-ab-segment-analyzer
PY-10
/code-review adversarial pass for p-hacking and Simpson's paradox
The part that actually matters: distribution
As enterprises standardize on a frontier model as their North Star, the bottleneck stops being “can we access a good model.” Everyone has the model. The bottleneck becomes can we distribute institutional knowledge through it fast enough that every analyst inherits the firm's best practice by default.
1. Zero-infrastructure
Commit to the repo. Every teammate who runs Claude Code inherits the skills automatically — no install step.
2. Packaged and portable
.skill files and plugins. Each skill packages into a single file that installs into a user's Claude profile with one click.
3. Live tools
A local or hosted MCP server wraps the pipelines' live connections — Databricks, Snowflake, Neo4j — as governed tools.
The same ten skills scale from one analyst's laptop to an org-wide standard without a rewrite. That's the property enterprises are actually buying when they pick a North Star model — not raw capability, but a substrate that institutional knowledge can be poured into and distributed through.
Source: Su, Sarah; Zhu, Kevin; Xiao, Emily; Alur, Rohan; Kang, Daniel (Bridgewater AIA Labs), in collaboration with Thinking Machines Lab — “Learning to Replicate Expert Judgment in Financial Tasks.” Thinking Machines Lab: News, Jun 30, 2026 · thinkingmachines.ai/news/learning-to-replicate-expert-judgment-in-financial-tasks. “Differentiated intelligence” is the paper's own closing phrase for this pattern — quoted, not coined here.
How to read this section
Verified
Stated directly in the cited primary source below.
Background
True and well-sourced, but from a different source than the primary citation, and not independently re-confirmed live in this pass. Confirm before citing live.
Proposed
The candidate's own architecture or application idea. Not benchmarked, not built, not reviewed by RA Capital.
Every factual claim below carries exactly one tag — so a reader who knows the source paper can see instantly which parts of this pitch are load-bearing evidence and which are extrapolation.
Headline result
Verified
Qwen3-235B
fine-tuned open-weight base model
84.7%
avg accuracy · vs 78.2% best frontier model tested
29.8%
fewer errors than the best frontier model
13.8×
cheaper inference per task than the frontier models evaluated
Panel A
The bottleneck
Verified
Six financial-triage judgment tasks drawn from investors' daily work:
Financial Article RelevancyCentral Bank Document RelevancyGeneric Document RelevancyAd Hoc Content LabelingDocument TruncationEmail Truncation
Naive prompt
~50%
Expert-written prompt
mid-70s
+ Auto prompt optimization
+0
┄ 80% = the accuracy the paper states investors need to trust the system daily. No prompting approach reached it — automatic prompt optimization added nothing further.
Newer isn't much better per dollar: GPT 5.4 costs 43% more than GPT 5.2 for only marginal accuracy gain.
An explicit prompt can only convey the intuition an expert can put into words; fine-tuning lets the model develop judgment a prompt can't fully articulate.
Panel B
The recipe — two tables, kept separate
Verified
Table 1 · Build-up — how the final recipe was assembled, in order.
Configuration
Accuracy
Pos. Class F1
Qwen3-235B base
44.8%
55.24%
+ GRPO (critic-free baseline)
73.48%
88.95%
+ Interleaved batching — one batch per task, round-robin (delta vs fully-mixed batching)
+12.1% †
—
+ CISPO loss, asymmetric clipping (delta vs importance-sampling-loss baseline)
+10.1% †
—
+ On-policy distillation — teacher promoted every 20 steps, only on a new validation-accuracy high (delta vs frozen-teacher baseline)
+3.1% †
—
Final recipe
84.66%
92.99%
† The paper reports these three as accuracy deltas against their own component baselines — not as rows in a single running total. Only the base, GRPO, and final-recipe rows are absolute accuracies.
Table 2 · Sensitivity check — each row = the final recipe with that one component removed, from the paper's own ablation table.
Read independently of Table 1: a build-up and a leave-one-out sensitivity check are different experiments — one is not a component of the other.
Panel C
Why CISPO
What the primary source states
Verified
“We used CISPO loss with asymmetric clipping to replace the standard importance-sampling loss… this performed best, improving accuracy by 10.1% over the importance-sampling baseline.”
The paper does not itself explain CISPO's internal mechanism — the block below is background, not the primary source.
Background — what CISPO is
Background
CISPO originates from MiniMax's MiniMax-M1 paper (arXiv:2506.13585, June 2025) — not from Thinking Machines or Bridgewater. Tinker and NVIDIA's NeMo-RL both implement it as a selectable loss function.
The problem.GRPO/PPO-style hard clipping on the policy ratio zeroes the gradient for tokens whose importance-sampling ratio spikes past the clip threshold. In long chain-of-thought reasoning those are exactly the rare, high-entropy “minority tokens” — “However,” “Recheck,” “Wait” — that steer the reasoning trajectory. The clip starves the model of gradient on precisely the pivot steps financial judgment depends on.
The fix. CISPO clips the importance-sampling weight itself under a stop-gradient (detach), so it acts as a constant coefficient; gradient flows exclusively through the log-policy term and no token is masked out. The clip is asymmetric — no lower bound, and a permissive upper bound (on the order of ~5.0) — which lets the model move aggressively when it is reinforcing a correct-but-rare expert judgment rather than damping it back toward the herd.
Working understanding, not a confirmed-today fact — the ~5.0 upper bound is implementation-specific; verify against arXiv:2506.13585 before citing live.
Deployment path — a first-90-days proposal
Proposed
The mechanics above are buildable today without a training cluster: Tinker(Thinking Machines Lab's fine-tuning API) exposes CISPO as a selectable loss and supports LoRA adapters over an open-weight Qwen3 base. The proposal: LoRA-fine-tune Qwen3 on TechAtlas-style landscape data and QRS anomaly logs, so the minority-token signal is preserved on the reasoning steps triage depends on — an autonomous research engine running high-stakes triage at a fraction of commercial-API inference cost.
Candidate proposal, not built or benchmarked. Confirm Tinker's supported base-model list and CISPO/LoRA mechanics at tinker-docs.thinkingmachines.ai before presenting as implemented.
Panel D
Where this lands in the RACap-POC stack
Proposed
Every bullet below is an application idea, not a result — none of this is benchmarked, built, or reviewed by RA Capital.
PY-04Clinical Trial PoS ClassifierProposed
Retaining minority reasoning-token signal is the kind of capability this task needs to weigh genetic and human-evidence signals against confounding trial variables. Genetic-evidence-backed target validation — including Mendelian randomization — is associated with meaningfully higher historical clinical success rates in the drug-development literature; confirm the specific citation and figure before saying a number out loud.
PY-09Planetary Health LCA ParserProposed
Interleaved batching across heterogeneous sustainability-report formats is the kind of technique that could help align extracted CO₂e / water / energy metrics to a strict taxonomy where frontier models tend to hallucinate tabular numerics from PDFs.
PY-01Biomedical Knowledge Graph ExtractorProposed
A domain-tuned model holding Pydantic + Neo4j schema compliance on the first pass would reduce retry loops in the extraction pipeline.
Panel E
Human-in-the-Loop & Data Safeguards
Proposed
Proposed architecture — designed by the candidate for this POC. Not built, not benchmarked, and not reviewed by RA Capital. It extends the same PreToolUse/PostToolUse rail described in the skills table above to define when a human gets pulled in.
1. Tiered autonomy, not an on/off switch
Proposed
L0Read-only (default)
PreToolUse allows SELECT only; any DDL/DML outside sandbox.* is denied.
L1Sandboxed write
Writes permitted only into sandbox.*/staging schemas; PostToolUse runs schema validation before a human ever sees the diff.
L2Production write
Requires an explicit human approval via the hook's ask path — no L2 action executes without a named person approving it, logged with identity and timestamp.
2. A sensitive-action allowlist, not model judgment
Proposed
Any tool call touching a table or field tagged pii, phi, or mnpi in the data catalog routes to ask automatically — regardless of what the agent says its intent is.
3. Data minimization before any cloud call
Proposed
A pre-processing hook strips or tokenizes patient identifiers and non-public deal terms beforecontent is allowed into Claude Code's or Tinker's context at all. Cloud-hosted agents only ever see de-identified or aggregated representations; raw record-level clinical or MNPI-tagged content is scoped to the local runtime — and even that access is logged and time-boxed.
4. Immutable, human-reviewable audit trail
Proposed
Every PreToolUse/PostToolUse decision — including every ask and who approved it — appends to a WORM log, exportable for SOC 2 / HIPAA / SEC review.
5. Circuit breaker
Proposed
A defined stop condition — e.g. three consecutive schema-validation failures, or any attempted write outside the allowlist — halts the session and requires a human to manually resume. Prevents a runaway loop from repeatedly hammering a production system.
6. Evidence-gated promotion, not self-promotion
Proposed
Nothing moves from sandbox.*into a real pipeline without two-person review — the same discipline as the paper's own on-policy-distillation rule (“promote the checkpoint to teacher only on a new validation-accuracy high, never trust the model's own say-so”), applied at the organizational layer instead of the training layer.
7. MNPI-specific scoping
Proposed
Any agent session that has touched non-public deal terms, unreleased trial readouts, or pre-decision investment theses gets zero outbound network tools — no web-fetch, no external API calls — for the rest of that session. The coding agent itself should never be a vector for MNPI leakage, intentional or not.
The operational envelope
One frozen base · LoRA per divisionProposed
A single frozen open-weight base model with LoRA adapters hot-swapped per division. Not built — confirm Tinker's actual supported base-model list and LoRA hot-swap mechanics at tinker-docs.thinkingmachines.ai before presenting this as implemented.
Hook perimeter — builtVerified
PreToolUse = read-only SQL perimeter: intercepts DROP / TRUNCATE / DELETE, exits non-zero, forces a SELECT-only rewrite. PostToolUse = auto-format + schema validation on every write. Cross-reference the orchestration mechanisms in the skills table above.
SkillMemoryBank — scoped preciselyVerified
A local IBM Granite runtime compresses interaction traces into a governed MEMORY.md. Zero egress applies to that compaction stage only — the primary Claude Code agent loop and Tinker fine-tuning call cloud-hosted APIs and see whatever is placed in their context. The real safeguard is upstream (Panel E, item 3): raw patient-level or non-public deal-level records are never pasted into a cloud-agent prompt in the first place; only schema-level, aggregated, or already-cleared content reaches Claude Code or Tinker.
Infographic · 9:16 board
Skill Layer at a glance
RACAP-POC SKILL LAYER
TOP 10 CLAUDE DATA ENGINEERING SKILLS FOR AN RA CAPITAL ANALYST
Ten reusable Claude Code skills — one per pipeline — that turn the RACap-POC from scripts into a governed, self-orchestrating stack