/* ============================================================ Model → Context sub-section. Data (the sheets) says WHAT; Context says WHY — the model's memory: judgment that lives in no cell. This is the answer to punch-list #2 ("Context face is metadata, not judgment"): here Context is first-class, encoded, validate-able judgment. Self-contained inline styling (mirrors about.jsx). ============================================================ */ // GENERAL context = the cookbook for this KIND of hub — Proxa-authored, // reusable across every customer, behaves like a Skill. It "transforms into" // specific once a model is uploaded (each specific item derivesFrom one of these). window.HUB_GENERAL_CONTEXT = { finance: [ { title: 'What a Finance hub is', judgment: 'A Finance hub is the encoded three-statement model of the business — Income Statement, Balance Sheet and Cash Flow — plus the schedules that feed them. Its job is to answer "how is the business doing, and what happens if…" from grounded numbers.' }, { title: 'The data products it typically holds', judgment: 'Assumptions, Income Statement, Balance Sheet, Cash Flow, plus schedules: GL Detail, Revenue Build, Working Capital, Debt, PP&E, Headcount, Capacity & Utilization.' }, { title: 'How it is normally built', judgment: 'Ground everything: raw system export → operational schedule (ODP) → analytical model (ADP) → statements. Nothing floats — every analytical number traces back to a source export.' }, { title: 'Checks that must always hold', judgment: 'The balance sheet must balance every period; cash flow ending cash must tie to the balance sheet; the statements must reconcile to the GL trial balance.' }, { title: 'Manufacturing vs. SaaS (this is a mfg template)', judgment: 'A manufacturing finance model turns on units × price, capacity/utilization, tolling vs. turnkey mix, and commodity input costs with pass-through pricing lag. (A SaaS model would instead turn on ARR, cohorts, churn and CAC — a different general context.)' }, ], // Research-lab domain (domains.jsx) — the cookbook for a typing hub. Same // five-item shape as finance: what it is, what it holds, how it's built, what // must hold, and the variant this template assumes. typing: [ { title: 'What a Typing hub is', judgment: 'A Typing hub is the encoded record of the assay — specimens, runs, sequences, and the allele assignments derived from them. Its job is to answer "what is this subject’s type, on what evidence, and is that still the current answer?"' }, { title: 'The data products it typically holds', judgment: 'Assignment Ledger, Ambiguity Queue, Re-resolution Diff, KIR–HLA Ligand Pairing, Cohort Allele Frequencies, Match Grades, Method Performance, QC & Proficiency Trend.' }, { title: 'How it is normally built', judgment: 'Nothing floats: trace or read → run → sequence → assignment. An assignment is a derivation, never a typed-in string, and it carries the method version and the IMGT/HLA release that produced it.' }, { title: 'Checks that must always hold', judgment: 'Every assignment cites a reference release; ambiguity is recorded rather than silently resolved; re-resolution against a newer release is reproducible; the ledger and the tables delivered to studies agree.' }, { title: 'SBT vs. NGS (this is a sequence-based-typing template)', judgment: 'SBT resolves exons by Sanger sequencing, so heterozygous cis/trans phase ambiguity is a property of the run and is resolved by allele-specific amplification. (An NGS template would instead turn on read depth, phasing and contamination thresholds — a different general context.)' }, ], }; // SPECIFIC context for the built Cascade Ridge Finance hub — the judgments // derived from THIS org's model, each deriving from a general cookbook item. window.FINANCE_SPECIFIC_CONTEXT = [ { title: 'The $1.81M Summit Trail write-off is intentional', judgment: 'The Aug-2025 Summit Trail Snacks bad-debt write-off is a deliberate one-time charge from a churned customer. Exclude it from adjusted EBITDA and do not smooth it across periods — it is a real, bounded loss, not a modelling artifact.', affects: ['Working Capital & AR', 'Income Statement'], owner: 'Jose Patel · CFO', status: 'Validated', derivedFrom: 'How it is normally built' }, { title: 'Margin recovery is mechanical, not performance', judgment: 'The H2-2025 oat & almond commodity spike cut gross margin 20.5% → 16.0%. Pass-through pricing lags input costs by ~2 quarters, so the recovery to 20.9% in H1-2026 is contractual catch-up — not an efficiency gain. Do not credit operations for it.', affects: ['P&L & Margin Bridge', 'Revenue Build', 'Assumptions'], owner: 'Trevor Garcia · FP&A', status: 'Validated', derivedFrom: 'Manufacturing vs. SaaS' }, { title: 'LEB-L5 capex depresses FY2026 free cash flow by design', judgment: 'The LEB-L5 line upgrade is a growth investment. The FY2026 free-cash-flow dip is planned capex — not a cost overrun or a liquidity concern. Read the cash-flow statement with this in mind before flagging the drawdown.', affects: ['PP&E Schedule', 'Cash Flow', 'Capacity & Utilization'], owner: 'Jose Patel · CFO', status: 'Validated', derivedFrom: 'Manufacturing vs. SaaS' }, { title: 'Verdant Valley structurally replaces the Summit Trail volume', judgment: 'Verdant Valley is ramping to ~$18M/yr and is intended to backfill the volume lost to the Summit Trail churn. Treat the customer-concentration shift as deliberate rebalancing, not erosion of the base.', affects: ['Customer Concentration', 'Revenue Build (bottom-up)'], owner: 'Jose Patel · CFO', status: 'Draft', derivedFrom: 'The data products it typically holds' }, ]; // Freshly derived from a just-uploaded model: same items, all still Draft // (nothing validated yet) — the state right after simulateUpload. window.FINANCE_DERIVED_SPECIFIC = window.FINANCE_SPECIFIC_CONTEXT.map((x) => ({ ...x, status: 'Draft' })); function ModelContextView({ general, specific, templateName, onUpload, domain }) { const pack = window.proxaDomain ? window.proxaDomain(domain) : null; const sourceNoun = (pack && pack.sourceNoun) || 'your model'; const C = { ink: 'var(--fg-dark)', base: 'var(--fg-base)', muted: 'var(--fg-muted)', line: 'var(--border-light, rgba(38,24,17,0.10))', panel: 'var(--bg-app)', green: 'var(--accent-green)', amber: '#A95B2E', blue: 'var(--accent-blue)', }; general = general || []; specific = specific || []; const Chip = ({ children }) => ( {children} ); const Status = ({ s }) => { const col = s === 'Validated' ? C.green : s === 'Draft' ? C.amber : C.blue; return ( {s} ); }; const SectionLabel = ({ kicker, text }) => (
{it.judgment}
{!gen && it.derivedFrom && (General is the cookbook for this kind of hub — reusable, from the template. Specific is yours — derived from your model, then validated to pin it as memory. General transforms into specific; it stays here to reference.
Use the assistant to upload {sourceNoun} — I’ll derive your specifics, instantiating each general item above for your work, then you validate them to pin them as memory.
{onUpload && ( )}Use the assistant to upload {sourceNoun}, and Claude will build your data products and derive your specific context from it.
{onUpload && ( )}
Each data product is a def declaring its inputs, logic,
checks, context and provenance; the org is a manifest wiring cross-domain edges; memory is COMPANY.md;
build scripts regenerate it all. Open any file to read the code behind the tables.