Inside CHEW's R&D floor.

Simulation — this public bay still shows a fixed, hand-built example. Nothing here is computed from a real subject on this page.

• Real capability names from CHEW's registry, shown only as illustrative labels.
• Internally, CHEW now has a working, deterministic multi-goal Parallel Futures engine: it compares 2–3 real paths — preserve, change a real fact, or resolve a different real requirement first — against one shared real baseline across two real goals, quantifying each path's effect where a goal's own chain supports it, and reporting an honest qualitative note (or an explicit "no declared relationship" note) everywhere else. It never picks a winner. It's gated internal-only, pending a real member identity system.

• Anyone's real facts or real requirement chain, on this public page — this bay isn't wired to that internal engine yet, so what you see here stays a fixed sketch rather than live output, to avoid implying member-specific modeling is live.

Preview — already live and fully built out at the Future Room. This bay shows a condensed view of the same real chain.

• The real transition_requirements chain, the real chosenRequirementKey CHEW computes today, and the real goal title, for one illustrative example scenario.
• This is now the same real chain CHEW's internal (not-yet-public) Scenario Modeling Foundation traces backward — outcome, required conditions, missing conditions, next action — using the identical dependency logic, not a second engine.

• A real member identity system — this reads the same shared illustrative scenario as the rest of the site, not a signed-in visitor's own facts.

Experimental — historical-state foundation active. Two of four gauges above are computed live from real data, the same as before; the deeper historical engine described below exists internally but isn't wired to this public bay yet, gated internal-only pending a real member identity system.

• Readiness and Constraint Pressure (labeled "Risk" here previously): the real resolved/unresolved requirement fraction and the real unresolved constraints count on file for this scenario — unchanged from before.
• Internally, CHEW now also stores real point-in-time state_snapshots of that same state, deduplicated by a real fingerprint so nothing gets recorded twice for no reason, and computes five real signals from them — Readiness, Constraint Pressure, Opportunity Access, Priority / Focus, and Capability Access. Each one honestly reports its own history depth: a single current reading with no comparison, a plain before/after change with one prior observation, or a real trend once two or more comparable snapshots exist. Never a guessed momentum score.
• Proven directly: after a real requirement fact and a real constraint were resolved for this repo's illustrative scenario, CHEW correctly said "Readiness improved since the last observation (33% → 67%)," "Constraint Pressure eased since the last observation (1 unresolved → 0 unresolved)," and "Priority shifted from “credit_score” to “down_payment_savings_cents.”"
• Opportunity Access now compares real canonical opportunity identity, not just a count — proven directly against the one real capability link this repo has (accounting/tax): when a real provider was replaced by a different real provider, CHEW correctly said "the count held at 1, but the real opportunities are different" (composition_changed) instead of wrongly calling it unchanged.

• Liquidity, income stability, net worth, asset growth, spending, debt, employment, cash runway, credit trend, or market exposure — none of that data exists anywhere in this schema yet, so none of it is estimated. This public bay also isn't wired to the internal historical engine yet, and snapshot-taking isn't yet triggered automatically by real portal events (a barrier resolving, an opportunity unlocking) — only on request, for now.

Experimental — backed by a real internal evidence-only discovery engine (lib/leverageModel.js), gated internal-only pending a real member identity system. This public bay still shows a fixed illustrative sketch, not live output.

• Internally, CHEW has found one real leverage item in this repo's seeded data: the real documented_income fact already satisfies the home goal's real requirement, and a real, human-authored goal_conflict_rules row explicitly declares that same fact also matters to the business-funding goal — so it can be preserved and reused instead of re-established.
• Dormant Capability detection is now real too, gated behind its own explicit capability_relevance_rules table (a human-authored row is the only way CHEW is allowed to call a capability relevant — no similarity guessing). CHEW currently has exactly one such rule, and correctly reports zero dormant capabilities right now, because this repo's provider network is genuinely empty — proven directly by temporarily seeding one real provider and watching the exact same rule correctly light up, then reverting it.
• The engine only returns an item when it can point to real evidence (a fact id, a requirement it satisfies, a declared rule, a live provider count) — it never brainstorms or infers a relationship, asset, or program that isn't already in the schema.

• This bay isn't wired to that internal engine yet, so what you see here stays a fixed sketch rather than live output, to avoid implying member-specific modeling is live.

Experimental — backed by real historical pattern detection, built directly on Economic Weather's state_snapshots. This public bay still shows a fixed illustrative sketch, not live output, gated internal-only pending a real member identity system.

• Internally, CHEW now derives real friction patterns purely from real state_snapshots — no second history table, no scenario data ever counted as a real observation. Four real pattern types: a requirement staying unresolved (persistent_requirement), the same requirement staying CHEW's current focus (repeated_focus), readiness not moving while other real state changes (readiness_stall), and a requirement resolving and then genuinely becoming unmet again (recurring_requirement) — each one requiring at least 2 real comparable observations before CHEW will use the word, and escalating language only at 3 or more.
• Proven directly: for this repo's illustrative scenario, CHEW correctly said "credit_score has remained unresolved across 3 meaningful observations," then correctly marked that same friction "resolved" once the requirement genuinely resolved, then correctly detected a real regression when it became unmet again — never inflating the count from a duplicate snapshot, never claiming a trend from a single observation.
• Every explanation ends by naming what CHEW does not know — never a guess at motivation, avoidance, or cause.

• Any psychological interpretation, ever — CHEW can say a requirement stayed unresolved, never why. Also doesn't yet distinguish a genuine waiting period (a seasoning requirement, a scheduled review date) from real friction, since this schema stores no waiting-period data to check against — a real, named limitation, not a guess dressed up as a distinction. Nothing is persisted to a database table; every result here is derived fresh from real snapshots each time, and this public bay isn't wired to that internal engine yet.

Simulation — this public bay still shows a fixed illustrative scenario, not live output from a real pair of goals.

• Real names of two capabilities from CHEW's registry, shown only as labels.
• Internally, CHEW now has a real, rule-backed Conflict Detection engine: it refuses to model an effect between any two goals unless a human has explicitly declared, in advance, exactly which real fact they share and why (never an inferred or "intuitive" relationship). Today it knows about exactly one real declared conflict — between this site's two illustrative example goals — deliberately not a dozen invented ones.

• This bay isn't wired to that internal engine yet, so what you see here stays a fixed sketch rather than live output, to avoid implying member-specific modeling is live.