Evulgare Simulations Product Evaluation and Development Brief

Full report

On this page

Executive summary

Evulgare’s simulations area is already more substantial than a typical interactive-demo gallery. The public product contains ten implemented simulations, each described as combining deterministic server logic, browser-based three-dimensional visualization, WebXR support, accessible table and text alternatives, API endpoints, proof invariants, and research traceability. The published software contract explicitly separates what the visual viewer demonstrates from what the deterministic Python engine proves, while public inputs are bounded, synthetic, and non-persistent.

The product’s strongest differentiator is therefore not three-dimensional graphics by themselves. It is the combination of:

• deterministic and inspectable state transitions;
• synchronized visual, tabular, narrative, event-log, and proof representations;
• explicit safety and non-operational boundaries;
• accessible, server-rendered fallbacks;
• research-to-code traceability;
• conservative treatment of uncertainty, authority, and assurance.

That foundation is unusually defensible. Replacing it with a conventional game-engine experience would risk producing a more visually impressive but less trustworthy product. The recommended strategy is to turn the existing collection into a browser-native assurance simulation workbench whose visual layer is more cinematic, immediate, and collaborative while the existing deterministic engines remain authoritative.

The central architectural recommendation is a two-layer model:

1. Authoritative assurance layer: versioned, pure Python domain engines, canonical scenario schemas, named invariants, deterministic event logs, cryptographic run digests, and accessible server-rendered outputs.
2. Experiential simulation layer: a TypeScript application with a modern workbench interface, Babylon.js as the preferred three-dimensional runtime, WebGPU enhancement with WebGL2 fallback, optional WebXR, worker-based computation, replay animation, comparison tools, collaboration, and carefully bounded authoring.

Babylon.js is the strongest default fit because it provides an integrated TypeScript/JavaScript engine, WebGPU and WebGL support, WebXR capabilities, and WebAssembly-based Havok physics under the Apache 2.0 license. Three.js remains a credible alternative where lower-level rendering control and a smaller abstraction layer are preferable. WebGPU should be treated as an enhancement rather than a baseline because browser and device support continues to vary, particularly across immersive XR contexts.

The highest-priority product changes are:

The proposed first product-grade release should be achievable in approximately four to six months with a cross-functional team of five to seven people, assuming the existing deterministic engines are preserved rather than rewritten. A planning range of roughly $800,000–$1.9 million is reasonable for that release under a loaded engineering-cost assumption of $8,000–$12,000 per person-week. The complete eighteen-month platform vision is estimated at $1.8–$4.4 million, excluding unusually expensive content production, specialized XR hardware laboratories, and sustained GPU-streaming infrastructure. These are directional planning estimates, not vendor quotations.

The desired product position is:

Evulgare is the interactive assurance workbench for inspecting how consequential autonomous and software-intensive systems make, constrain, explain, and prove decisions.

This position is more distinctive than competing directly with general-purpose game engines, engineering solvers, or digital-twin platforms. Those products optimize rendering, physical fidelity, model construction, or industrial scale. Evulgare should optimize answerability, provenance, accessible inspection, safe experimentation, and proof-linked interaction.

Current-state audit

Audit scope and confidence. This assessment covers the public, unauthenticated simulations pages, representative simulation experiences, published proof material, and public accessibility and security statements. It is not a source-code audit, penetration test, browser-profile capture, Lighthouse run, or authenticated-workspace review. Findings about publicly described behavior have high confidence; findings about undocumented implementation details and actual runtime performance have lower confidence.

Audit scorecard

Feature and content analysis

The landing page’s main strength is clarity of intent. It immediately identifies desktop three-dimensional rendering, WebXR, accessible fallbacks, synthetic boundaries, and the ten implemented scenes. It also distinguishes visualization from deterministic proof and explains the run–derive–verify–render contract.

Its main weakness is that it communicates richness almost entirely through text. The page does not quickly answer several practical questions a prospective user is likely to have:

• Which simulation should I start with?
• Which ones are introductory versus advanced?
• How long does each experience take?
• Which ones work well on mobile or XR?
• Which offer replay, comparison, branching, or export?
• Which concepts are prerequisites for others?
• Can I save, share, embed, or modify a scenario?
• What will I learn or be able to prove after completing one?

A more effective gallery would function as an explorer rather than a catalog. Each simulation card should show an animated or interactive preview, subject category, estimated completion time, difficulty, available modes, relevant audiences, proof count, and device capability. Filters should support topic, simulation mechanic, audience, complexity, duration, input method, and accessibility mode.

The individual simulation pages show a stronger interaction model than the landing page implies. The Accountability Evidence Room, for example, combines bounded controls, presets, proof checks, disclaimers, keyboard guidance, visual output, tables, textual interpretation, and an authoritative fallback. The Autonomous Drone Control Assurance Lab goes much further with replay, timeline events, candidate comparison, supervisory control, health gates, proof evidence, post-run summaries, export, comparison, and counterfactual branching.

The product should standardize those advanced capabilities. A visitor should not have to learn a different page structure or hunt through a long page for each simulation. A common workbench can preserve simulation-specific controls while providing invariant locations for:

• simulation status;
• scenario presets;
• run controls;
• visual scene;
• accessible representation switcher;
• event timeline;
• proof inspector;
• comparison;
• export and sharing;
• research traceability;
• performance and capability diagnostics.

Accessibility assessment

The existing approach is directionally excellent. The site targets WCAG 2.2 AA and emphasizes keyboard navigation, visible focus, semantic structure, reduced motion, and multiple representations. WCAG 2.2 organizes accessibility under four principles—perceivable, operable, understandable, and robust—and requires a combination of machine testing and human evaluation rather than reliance on automated checks alone.

The most valuable existing accessibility choice is that the table and text views are not merely afterthoughts. Representative simulation pages identify them as authoritative equivalents and leave useful server-rendered information available when JavaScript or the renderer is unavailable.

The remaining gap is evidence. “Targets WCAG 2.2 AA” should mature into a public conformance and testing program covering:

Performance assessment

The public architecture has one important performance advantage: critical explanatory content is rendered independently of the three-dimensional client. That means a failed or slow renderer does not necessarily result in a blank page.

However, increasingly sophisticated visuals can easily undermine that advantage if engine code, high-resolution assets, XR libraries, physics, analytics, collaboration, and authoring tools are loaded eagerly. The redesign should therefore enforce three principles:

1. Do not download the three-dimensional engine on the gallery page.
2. Do not initialize XR, physics, collaboration, or authoring until requested.
3. Do not let visual update work block accessible state updates or input responsiveness.

For public pages, recommended field-performance gates are the current “good” Core Web Vitals thresholds: Largest Contentful Paint no greater than 2.5 seconds, Interaction to Next Paint no greater than 200 milliseconds, and Cumulative Layout Shift no greater than 0.1 at the 75th percentile. Resource prioritization, CDN delivery, explicit media dimensions, and the removal of unnecessary main-thread JavaScript are among the principal means of achieving those targets.

Competitive landscape

The comparison below intentionally includes both platforms and frameworks. They solve different layers of the problem: browser rendering, native engine development, streamed high-fidelity graphics, industrial digital twins, systems simulation, engineering analysis, and verification. Evulgare should selectively adopt their strongest patterns rather than imitate any one product wholesale.

Platform and framework comparison

Competitive conclusions

Babylon.js versus Three.js. Babylon.js is the recommended default because Evulgare needs an application platform rather than only a renderer. Integrated XR, physics, inspection tools, material systems, and WebGPU fallback reduce the amount of platform code that must be maintained. Three.js is preferable only if the existing renderer is already deeply bespoke or if maintaining a thinner rendering abstraction is a strategic priority.

Unity and Unreal. Both deliver mature real-time authoring, but neither should replace the current web and Python architecture. Unity web deployments inherit browser-specific constraints and do not yet make WebGPU a conservative production foundation. Unreal’s Pixel Streaming can deliver exceptional graphics, but each active high-fidelity session consumes server-side GPU capacity and introduces latency, orchestration, and cost concerns.

Omniverse. Omniverse becomes strategically relevant if Evulgare enters industrial digital twins, OpenUSD exchange, synthetic-data generation, or shared enterprise scenes. Its OpenUSD and extension model could support premium integrations, but introducing it into the public product now would add more platform complexity than user value.

AnyLogic, SimScale, and Simulink. These are the most useful conceptual competitors. They demonstrate that serious simulation platforms are differentiated by experiment design, parameter sweeps, scenario management, verification, integration, and reproducibility—not only rendering. Evulgare should borrow those workflow patterns while preserving its unique emphasis on assurance structure, proof, and accessible inspection.

Defensible product differentiation

Evulgare should avoid positioning itself as:

• a general game engine;
• a high-fidelity CFD or finite-element solver;
• an operational autonomy-control interface;
• a universal digital-twin environment;
• an automated safety-certification system.

Its strongest competitive space is the intersection of simulation, assurance, provenance, governance, and explanation. The public proof material itself cautions that running a simulation is not certification and does not eliminate the gap between a model and reality.

A useful category formulation is:

Assurance simulation and decision-provenance platform

The category promise would be that every meaningful visual transition can be traced to structured inputs, deterministic domain logic, named proof conditions, an event history, and an accessible representation.

Product roadmap and feature proposals

Effort scale. Low means approximately one to three person-weeks; medium means four to eight person-weeks; high means nine to twenty person-weeks. Estimates include implementation and routine testing but not extensive original research, regulatory certification, or specialized content creation.

Impact scale. High indicates a substantial effect on adoption, comprehension, retention, enterprise value, or platform leverage. Medium indicates valuable but non-foundational improvement.

Short-term product work

Mid-term platform work

Long-term platform work

Recommended delivery roadmap and costs

These estimates assume a blended team consisting of a product or engineering lead, two to three frontend/graphics engineers, two backend/platform engineers, a product designer with accessibility expertise, and shared quality/security support. Content-heavy simulation authoring may require additional subject-matter expertise.

Architecture and technology recommendations

Target architecture

flowchart LR
    subgraph Client["Browser and XR client"]
        SSR["Server-rendered semantic HTML\nTables · narratives · proof summaries"]
        SHELL["TypeScript workbench\nReact · state machine · design system"]
        RENDER["Babylon.js renderer\nWebGPU with WebGL2 fallback"]
        WORKERS["Web Workers and optional WASM\nLayout · interpolation · visual effects"]
        A11Y["Accessible representation adapter\nARIA · tables · live summaries"]
        LOCAL["Ephemeral local state\nIndexedDB only when explicitly enabled"]

        SHELL --> RENDER
        SHELL --> WORKERS
        SHELL --> A11Y
        SHELL --> LOCAL
        SSR --> SHELL
    end

    CDN["CDN and object storage\nJS · glTF · KTX2 · exports"]
    EDGE["WAF · API gateway · rate limits\nAuthentication · request IDs"]
    API["FastAPI application layer\nOpenAPI · validation · orchestration"]
    ENGINE["Pure deterministic Python engines\nNamed invariants · canonical digests"]
    REALTIME["Realtime service\nWebSocket presence and collaboration"]
    JOBS["Asynchronous workers\nBatch runs · exports · parameter sweeps"]
    PG["PostgreSQL\nTenants · workspaces · metadata"]
    REDIS["Redis\nPresence · cache · quotas · short-lived state"]
    BUS["NATS JetStream or equivalent\nVersioned domain events"]
    OBJECTS["S3-compatible storage\nAssets · reports · signed packages"]
    OTEL["OpenTelemetry collector\nTraces · metrics · logs"]
    GPU["Optional GPU-streamed laboratories\nUnreal or Omniverse over WebRTC"]

    Client --> CDN
    Client --> EDGE
    EDGE --> API
    EDGE --> REALTIME
    API --> ENGINE
    API --> PG
    API --> REDIS
    API --> BUS
    API --> OBJECTS
    REALTIME --> REDIS
    REALTIME --> BUS
    JOBS --> ENGINE
    JOBS --> BUS
    JOBS --> OBJECTS
    API --> OTEL
    REALTIME --> OTEL
    JOBS --> OTEL
    Client -. premium session .-> GPU
    GPU --> EDGE

The authoritative boundary is deliberate. Babylon.js, WebGPU, physics, interpolation, particles, and cinematic camera behavior improve the representation, but they must not become the source of truth for proof-bearing state. The server’s deterministic engine should remain authoritative unless a future computation kernel is independently specified, versioned, and proven equivalent.

Technology decision matrix

FastAPI’s official capabilities include OpenAPI and JSON Schema generation, typed Python request models, WebSocket endpoints, and documented test-client patterns, making it a pragmatic modernization path without abandoning the existing Python domain layer.

Canonical data contracts

The platform should define a versioned envelope similar to:

{
  "schemaVersion": "2.0.0",
  "simulationId": "autonomy-assurance-lab",
  "simulationVersion": "2.3.1",
  "engineVersion": "1.8.0",
  "scenario": {
    "presetId": "unexpected-object-baseline",
    "parameters": {}
  },
  "run": {
    "id": "content-addressed-or-generated-id",
    "startedAt": "ISO-8601 timestamp",
    "determinismProfile": "python-authoritative-v1"
  },
  "events": [],
  "outputs": {},
  "metrics": {},
  "proof": {
    "invariants": [],
    "canonicalDigest": "..."
  },
  "representations": {
    "narrative": {},
    "table": {},
    "scene": {}
  },
  "provenance": {
    "researchReferences": [],
    "parentRunId": null,
    "branchEventIndex": null
  }
}

Canonical serialization must specify field ordering or canonical JSON rules, numerical precision, Unicode treatment, absent-versus-null behavior, and schema-version inclusion. Otherwise, equivalent records may produce different digests across languages or runtime versions.

A digest proves integrity relative to the selected canonical representation; it does not prove that assumptions are correct, that reality matches the model, or that a system is certified. Evulgare’s existing proof language already preserves this distinction and should continue doing so.

Migration sequence

Experience, quality, security, and commercial strategy

Interaction and visual design

The desired visual direction should be technical, spatial, and cinematic without becoming decorative or militarized. A productive design vocabulary would combine:

• a restrained dark or neutral instrument-panel foundation;
• clear typographic hierarchy;
• semantic status chips;
• animated edges, pulses, volumes, uncertainty fields, and state transitions;
• camera moves tied to events rather than idle spectacle;
• subtle depth, lighting, and post-processing;
• diagrams and overlays that expose proof structure;
• visible identifiers and text labels so that color is never the sole carrier of meaning.

The gallery should use still or lightweight animated previews. Motion should pause when cards leave the viewport, when the page is hidden, or when reduced motion is requested. Full engine initialization should occur only after a user launches a simulation.

A recommended desktop workbench structure is:

┌──────────────────────────────────────────────────────────────────────────────┐
│ Simulation title · mode · capability · run status · save/share/export       │
├─────────────────┬──────────────────────────────────────┬─────────────────────┤
│ Scenario        │                                      │ Proof inspector     │
│                 │          Interactive scene           │                     │
│ Presets         │                                      │ Invariants          │
│ Parameters      │          Selection overlays          │ Evidence            │
│ Interventions   │          Camera / view tools         │ Defeaters           │
│ Run controls    │                                      │ Research links      │
├─────────────────┴──────────────────────────────────────┴─────────────────────┤
│ Event timeline · play · step · speed · bookmarks · baseline/variant diff    │
├──────────────────────────────────────────────────────────────────────────────┤
│ View: Visual | Table | Narrative | Metrics | Event log | Raw evidence       │
└──────────────────────────────────────────────────────────────────────────────┘

On mobile, the same information hierarchy should become a scene-first layout with a persistent status header and ordered tabs:

[Status and Run]
[Scene / diagram]
[Controls] [Timeline] [Proof] [Table] [Narrative]

Mobile users should not receive a compressed desktop dashboard. Complex tables should support card representations, sticky row headers, column selection, and downloadable full data.

Guided interaction model

Each simulation should have three explicit modes:

Guided mode should never present itself as a simplistic video tour. It should still execute the real deterministic engine and display authentic proof state. The difference is controlled disclosure, not a separate demonstration.

User flow

flowchart TD
    A["Arrive at Simulation Explorer"] --> B["Choose goal\nLearn · Evaluate · Build · Govern"]
    B --> C["Filter or accept recommendation"]
    C --> D["Capability and accessibility preflight"]
    D --> E{"Select experience mode"}
    E -->|Guided| F["Learning objective and narrated baseline"]
    E -->|Explore| G["Choose preset and bounded controls"]
    E -->|Expert| H["Open full workbench and raw evidence tools"]

    F --> I["Validate scenario"]
    G --> I
    H --> I

    I --> J["Execute deterministic run"]
    J --> K["Synchronize visual, table, narrative,\nmetrics, event log, and proof"]
    K --> L["Inspect event timeline and invariants"]
    L --> M{"Next action"}
    M -->|Change bounded input| N["Create variant or counterfactual"]
    N --> J
    M -->|Compare| O["Baseline-versus-variant analysis"]
    M -->|Collaborate| P["Share workspace or live review"]
    M -->|Export| Q["Evidence package or report"]
    M -->|Learn more| R["Research traceability and glossary"]

    O --> S["Summary of changed causes,\noutputs, and proof conditions"]
    P --> S
    Q --> S
    R --> S
    S --> T["Recommended next simulation or challenge"]

Accessibility requirements

Every interactive capability should have a representation-level acceptance rule:

Automated accessibility tools are useful but insufficient. WCAG conformance requires human judgment for many interaction and content questions, so release testing should include keyboard-only operation, multiple screen readers, zoom and reflow, reduced-motion verification, and comprehension testing with representative users.

Performance and scalability targets

Core Web Vitals thresholds in the table correspond to current official “good” thresholds, while the other values are proposed product budgets that should be validated against actual scenes and user hardware.

The performance strategy should include:

• route-level and feature-level code splitting;
• progressive glTF and texture loading;
• KTX2/Basis texture compression;
• meshopt or Draco geometry compression where it improves total time;
• instancing for repeated nodes and markers;
• dynamic resolution scaling;
• quality tiers for shadows, post-processing, particles, and antialiasing;
• object pooling for transient visual effects;
• worker-based event parsing and interpolation;
• suspension of rendering when hidden or static;
• explicit cleanup of GPU resources on route changes;
• asset caching through immutable content hashes;
• CDN delivery close to users;
• stateless API scaling;
• queues for long-running or batch work;
• separate scaling policies for APIs, realtime connections, workers, and GPU streams.

WebGPU offers more direct access to modern GPU functionality and compute capabilities than WebGL, but it should remain capability-gated because availability and production readiness vary by browser, platform, and embedded context. WebXR also requires secure contexts and remains unevenly supported.

Testing strategy

Recommended tools include Vitest, Testing Library, Playwright, axe-core, pytest, Hypothesis, Schemathesis, Lighthouse CI, WebPageTest, k6, OWASP ZAP, Semgrep or CodeQL, Trivy, Syft/Grype, Renovate or Dependabot, and browser/device laboratories.

Security and privacy

The current public posture already describes several appropriate controls: secure cookies, CSRF protection, role-based administration, Argon2id password hashing, restrictive headers, least privilege, and append-oriented auditing. The expansion into accounts, persistence, collaboration, imports, plugins, and marketplaces materially increases the attack surface.

The security model should be organized around the following boundaries:

OWASP ASVS provides a suitable basis for defining and verifying application-security controls. A strong Content Security Policy is an important defense-in-depth measure, and API inputs should be validated for type, range, format, allowed values, and structural limits rather than sanitized into silently accepted forms.

Analytics and product measurement

The analytics program should distinguish three categories:

Core product metrics should include:

• explorer-to-launch conversion;
• time to first successful run;
• guided-mode completion;
• proof-inspector discovery;
• baseline-versus-variant completion;
• export and share rates;
• fallback and renderer-failure rates;
• return rate by audience track;
• simulations completed per active user;
• API activation and successful first call;
• collaboration sessions and annotation resolution;
• accessibility-mode task success;
• performance by renderer and device tier.

Monetization model

These prices are product-planning proposals rather than observed Evulgare prices or externally validated willingness-to-pay figures. They should be tested through customer discovery before implementation.

Community and engagement

Community functionality must reinforce the product’s assurance values rather than imitate entertainment-platform engagement indiscriminately.

APIs and plugins. Publish a clear developer portal, runnable examples, API status, changelog, schema registry, SDKs, sandbox keys, rate-limit dashboards, and plugin certification levels. Plugins should be categorized as renderers, importers, exporters, metrics, proof views, simulation engines, integrations, or educational modules.

Multiplayer. Begin with presenter-led collaborative review rather than shared physics. Useful roles include presenter, analyst, reviewer, observer, and facilitator. High-value features include synchronized replay, shared selection, laser-pointer-style presence, event annotations, questions, decision records, and branch proposals.

Leaderboards. Avoid ranking users by speed, maximum system authority, aggressive intervention, or apparent operational performance. Appropriate rankings and badges could reward:

• completing proof-inspection exercises;
• identifying hidden assumptions or stale evidence;
• choosing justified abstention;
• explaining why two runs diverged;
• creating well-documented public scenarios;
• resolving peer-review comments;
• writing high-quality plugins;
• reproducing published runs.

Community gallery. Public artifacts should display provenance, author, license, version, moderation status, schema compatibility, proof coverage, safety classification, fork history, and reproducibility status. “Featured” placement should reflect educational quality and evidence discipline, not only popularity.

Engagement loops. Recommended loops include simulation learning paths, weekly bounded challenges, curated expert walkthroughs, scenario-of-the-month reviews, reproducibility badges, contributor profiles, plugin showcases, classroom cohorts, and research-paper companion simulations.

Developer-facing implementation prompt

The following prompt is designed to be given directly to an AI engineering system, a software-development team, or a combination of both.

You are the principal engineering and product implementation team for the next generation
of Evulgare Simulations.

MISSION

Transform the existing Evulgare simulations collection into a bleeding-edge, visually exciting,
accessible, deterministic, collaborative assurance simulation workbench.

The resulting product must feel materially more advanced and immediate than the current
text-heavy gallery while preserving and strengthening its most important properties:

1. Pure, deterministic, authoritative simulation logic.
2. Named proof invariants and canonical run digests.
3. Synchronization among visual, tabular, narrative, metric, event-log, and proof views.
4. Complete non-3D and non-XR task parity.
5. Explicit synthetic, abstract, and non-operational safety boundaries.
6. Research-to-code traceability.
7. No universal score that averages away missing authority, uncertainty, stale evidence,
   violated constraints, or failed proof conditions.
8. Public inputs remain ephemeral unless the user explicitly saves a run to an authenticated
   workspace.
9. The renderer is never the authoritative source of proof-bearing state.
10. Simulation output must never be presented as certification or as elimination of the
    model-to-reality gap.

PRODUCT POSITION

Build an “assurance simulation and decision-provenance platform.”

The product should help users inspect:

- what inputs and assumptions were supplied;
- how state changed;
- which events caused later outcomes;
- where uncertainty, authority, trust, purpose, or evidence became insufficient;
- which invariant passed, failed, or remained unknown;
- how two deterministic runs differ;
- what is visual interpretation versus authoritative engine output;
- how a run can be replayed and independently inspected.

PRIMARY USERS

Design for these user classes:

- First-time learner or student
- Assurance or safety engineer
- Autonomy researcher
- System and software architect
- Technical evaluator or independent reviewer
- Governance, policy, or legal-process stakeholder
- Program or executive decision-maker
- Educator or curriculum designer
- API and plugin developer
- Enterprise workspace administrator

Do not assume that all users understand terms such as provenance, defeater, epistemic
uncertainty, authority gate, distribution shift, or invariant. Provide layered explanations
without diluting the expert representation.

NON-OPERATIONAL SAFETY BOUNDARIES

Maintain hard product prohibitions against introducing or producing:

- real-world targeting coordinates;
- weapon ranges or payload parameters;
- firing solutions;
- force authorization;
- operational intelligence;
- live vehicle, weapon, actuator, or command-and-control interfaces;
- instructions that convert an abstract scene into operational deployment;
- hidden external side effects from public simulations.

Use abstract identifiers, normalized units, synthetic entities, fictional organizations,
bounded scalar controls, and null sinks.

Any future import, plugin, AI, or authoring feature must enforce these boundaries through
schema validation, allowlists, permissions, moderation, and tests.

CORE TECHNICAL DIRECTION

Frontend:
- TypeScript
- React
- Vite for the incrementally mounted simulation workbench
- Babylon.js as the preferred 3D runtime
- WebGPU when capability checks pass
- WebGL2 as a supported fallback
- WebXR as an optional enhancement
- React Aria or equivalent accessible primitives
- XState or explicit reducer-based state machines
- TanStack Query for server-state coordination
- Zod-generated or JSON-Schema-generated client validation
- Web Workers with Comlink for parsing, layout, interpolation, and heavy visual computation
- Optional Rust/WASM only for measured hotspots or shared deterministic kernels

Backend:
- Preserve existing pure Python domain-engine functions
- Introduce FastAPI incrementally beside Flask
- Pydantic models and generated OpenAPI
- Versioned Scenario, Run, Event, Metric, Proof, Representation, Asset, Annotation,
  Capability, and PluginManifest schemas
- PostgreSQL for users, tenants, workspaces, saved-run metadata, annotations, API keys,
  and billing records
- Redis for presence, short-lived collaboration state, caching, and rate limiting
- NATS JetStream or an equivalent event stream for jobs, webhooks, exports, and
  collaboration events
- S3-compatible object storage for immutable assets, reports, evidence packages,
  and signed plugin packages
- OpenTelemetry for traces, metrics, and logs

Hosting:
- CDN for static application and scene assets
- Managed container runtime for APIs, collaboration, and asynchronous workers
- Managed PostgreSQL and Redis
- WAF and API gateway
- Region-aware deployment for paid collaboration
- Separate optional GPU pools for future Unreal or Omniverse streaming

Do not rewrite all engines or simulations at once.
Use a strangler migration and scene-adapter architecture.

AUTHORITATIVE RUN CONTRACT

Every run must have:

- schemaVersion
- simulationId
- simulationVersion
- engineVersion
- normalized bounded inputs
- deterministic event history
- explicit outputs and metrics
- named invariant results
- invariant status: pass, fail, or unknown
- invariant evidence and rationale
- canonical digest
- representation metadata
- provenance and branch metadata
- research references
- generation timestamp as metadata, not as an input to deterministic computation
- clear statement of limitations

Specify canonical serialization:

- field ordering or a recognized canonical JSON method;
- number precision and rounding;
- handling of integers versus floating-point numbers;
- Unicode normalization;
- null versus omitted fields;
- arrays and event ordering;
- inclusion of schema and engine versions;
- binary asset references;
- digest algorithm and version.

The same normalized input, schema version, simulation version, and engine version must
produce the same authoritative output, event history, invariant results, and digest.

VISUAL PRODUCT DIRECTION

Create a sophisticated technical-instrument visual language:

- clear information hierarchy;
- dark or neutral workspace with strong contrast;
- restrained glow, particles, edge animation, volumetric fields, and post-processing;
- semantic status chips;
- camera animation driven by meaningful events;
- readable labels and overlays;
- optional cinematic mode;
- reduced-motion mode;
- no information conveyed by color alone;
- no decorative motion that obscures proof state;
- no military or operational aesthetic that contradicts the synthetic assurance purpose.

The experience must look exciting because causal structure becomes visible, not because
unrelated effects are added.

EPIC: SIMULATION EXPLORER

Replace the static catalog experience with a visual explorer.

Required capabilities:
- card or grid representation for all simulations;
- static preview or lightweight paused/muted animation;
- title, summary, topic, audience, difficulty, estimated duration, proof count,
  research-source count, and supported modes;
- filters for topic, audience, difficulty, duration, interaction type, WebXR,
  guided mode, comparison, export, and authoring compatibility;
- sorting by recommended, newest, duration, complexity, and popularity;
- recommended paths such as Learn, Evaluate, Build, and Govern;
- recently viewed and favorited simulations for consenting users;
- shareable filter URLs;
- full keyboard operation;
- no loading of the full 3D engine before a simulation is opened.

Acceptance tests:
GIVEN the explorer is loaded
WHEN no simulation is opened
THEN the Babylon.js runtime and large scene assets are not downloaded.

GIVEN a keyboard-only user
WHEN the user applies a topic filter and opens a simulation
THEN focus order is logical, filter state is announced, and the selected simulation opens
without pointer interaction.

GIVEN a URL containing valid explorer filters
WHEN the page loads
THEN matching filters and results are restored.

GIVEN reduced motion
WHEN previews are visible
THEN animated previews are paused or replaced with still images.

EPIC: CAPABILITY PREFLIGHT

Detect:
- WebGPU availability;
- WebGL2 availability;
- WebXR availability;
- reduced-motion preference;
- high-contrast or forced-colors behavior where observable;
- pointer and touch capabilities;
- approximate memory or performance tier using privacy-respecting signals;
- network constraints;
- renderer initialization errors.

Offer:
- Recommended mode
- High-fidelity mode
- Low-power mode
- Accessible table and narrative mode
- XR mode only when supported

Acceptance tests:
GIVEN WebGPU is unavailable and WebGL2 is available
WHEN the user opens a scene
THEN the scene operates through WebGL2 with identical authoritative outputs.

GIVEN neither renderer initializes
WHEN the scene route loads
THEN controls, run execution, table, narrative, timeline, and proof remain usable.

GIVEN XR is unavailable
WHEN the user opens capability information
THEN the interface explains that XR is optional and does not imply reduced analytical
functionality.

EPIC: UNIFIED WORKBENCH

Desktop layout:
- top command and status bar;
- left scenario and controls panel;
- central scene;
- right proof and evidence inspector;
- bottom event timeline;
- representation tabs for Visual, Table, Narrative, Metrics, Event Log, and Raw Evidence.

Mobile layout:
- scene-first or summary-first view;
- ordered tabs or drawers;
- persistent run status;
- no tiny multi-column desktop reproduction;
- touch targets meeting accessibility requirements;
- tables that can be transformed into cards or narrowed to selected columns.

All panels must be:
- resizable where useful;
- collapsible;
- keyboard reachable;
- restorable to defaults;
- represented in URL or workspace preferences only where appropriate;
- capable of announcing important state changes without excessive screen-reader verbosity.

Acceptance tests:
GIVEN a user switches from Visual to Table at event 12
THEN the table reflects event 12 and the selected entity.

GIVEN a user changes viewport from desktop to mobile
THEN no run, event index, selection, or valid unsaved scenario input is lost.

GIVEN the proof panel is collapsed
WHEN an invariant changes to failed
THEN a non-color status indicator appears and the user can navigate directly to the failure.

EPIC: GUIDED, EXPLORE, AND EXPERT MODES

Guided:
- state a learning objective;
- introduce concepts incrementally;
- provide a glossary;
- explain why each important transition occurred;
- provide skip, back, restart, and exit controls;
- complete a representative baseline in about three minutes;
- use the real engine, not a prerecorded imitation.

Explore:
- present curated presets;
- expose commonly understood bounded controls;
- provide compare, replay, and contextual explanation.

Expert:
- expose all public allowlisted inputs;
- raw event and proof records;
- API request example;
- engine and schema versions;
- export options;
- advanced camera, overlay, and diagnostics controls.

Acceptance tests:
GIVEN a new user starts Guided mode
WHEN the user completes the baseline
THEN the user receives a summary of inputs, decisive events, proof results, limitations,
and recommended next exploration.

GIVEN a user switches from Guided to Expert
THEN the valid scenario and completed run remain available.

GIVEN a glossary term appears
THEN it is accessible by keyboard, touch, and screen reader without forcing a navigation away.

EPIC: REPLAY AND TIMELINE

Standard controls:
- play;
- pause;
- previous event;
- next event;
- scrub;
- speed;
- jump to beginning or end;
- jump to proof change;
- bookmarks;
- event categories;
- search;
- selected-entity filtering.

The canonical run history is immutable.
Replay is a view over history.
A counterfactual creates a new run with parentRunId and branchEventIndex.
It never modifies the parent history.

Acceptance tests:
GIVEN a completed run
WHEN the user scrubs from event 20 to event 5
THEN visual, table, narrative, metrics, proof, and selection all reflect event 5.

GIVEN a counterfactual is created at event 8
THEN the original run remains byte-for-byte unchanged and the new run identifies its
parent and branch event.

GIVEN two users observe the same hosted replay
WHEN the presenter changes event index
THEN observers receive the new position within the collaboration latency objective,
while retaining the ability to detach locally.

EPIC: BASELINE AND VARIANT COMPARISON

Compare:
- normalized input differences;
- event-sequence differences;
- output and metric differences;
- proof status differences;
- evidence and rationale differences;
- digest and version differences;
- branch provenance;
- visual split view;
- optional synchronized cameras;
- overlay mode only where it remains comprehensible.

Do not display a single aggregate “better” score.
Do not hide failed or unknown invariants behind a favorable average.

Acceptance tests:
GIVEN two runs with one changed input
WHEN comparison opens
THEN the changed input, first divergent event, resulting output differences, and proof
differences are identifiable.

GIVEN one run has a failed invariant
THEN the comparison cannot collapse the failure into an aggregate score.

GIVEN the two runs use different engine versions
THEN the comparison displays a version warning and explains that differences may not be
attributable only to scenario inputs.

EPIC: EVIDENCE EXPORT AND SHARE

Support:
- canonical JSON package;
- human-readable HTML or PDF report;
- optional CSV extracts for tables and metrics;
- signed share links;
- privacy-safe anonymous share mode;
- workspace-scoped share mode;
- import and validation;
- deterministic replay where the required engine version is available.

The evidence package includes:
- schema and engine versions;
- normalized inputs;
- event history;
- outputs;
- proof results;
- digest;
- narrative;
- research references;
- limitations;
- provenance;
- verification result after import.

Acceptance tests:
GIVEN a valid exported package
WHEN it is imported into a compatible environment
THEN its digest validates and the replay reaches identical authoritative states.

GIVEN a package has been modified
WHEN it is imported
THEN validation fails clearly and no claim of equivalence is shown.

GIVEN an anonymous user creates a share link
THEN the link contains or references only the intended run package and no browser fingerprint,
account data, or unrelated session information.

EPIC: VERSIONED API AND SDK

Build FastAPI endpoints for:
- list simulations;
- retrieve simulation schema;
- validate scenario;
- execute run;
- retrieve run;
- retrieve event slice;
- retrieve proof;
- compare runs;
- export package;
- submit batch;
- retrieve batch status;
- create webhook;
- verify package;
- health and readiness.

Requirements:
- OpenAPI 3 documentation;
- generated TypeScript and Python clients;
- idempotency keys for run and batch creation;
- structured error codes;
- request IDs;
- schema version negotiation;
- explicit deprecation policy;
- pagination where required;
- quotas and rate-limit headers;
- HMAC-signed webhooks;
- no silent coercion of illegal input.

Acceptance tests:
GIVEN an out-of-range scalar
WHEN a run request is submitted
THEN the API rejects it with a structured validation error and does not clamp silently unless
the schema explicitly defines clamping.

GIVEN the same idempotency key and identical body
WHEN a request is retried
THEN the same run result or run identifier is returned.

GIVEN the same idempotency key and a different body
THEN the request is rejected as an idempotency conflict.

GIVEN a generated SDK
WHEN contract tests run
THEN all supported endpoints serialize and deserialize against the published schema.

EPIC: BOUNDED AUTHORING STUDIO

Allow qualified users to create synthetic scenarios using:
- approved entity templates;
- abstract relationships;
- event sequences;
- bounded parameters;
- allowlisted metrics;
- display rules;
- narrative templates;
- references;
- explicit limitations;
- proof-view configuration.

Do not initially allow arbitrary code execution.
Do not permit public authors to introduce external network calls, actuator commands,
unrestricted files, or prohibited operational fields.

Provide:
- live schema validation;
- preview;
- accessibility preview;
- proof-coverage checklist;
- versioning;
- draft and publish workflow;
- license selection;
- moderation status;
- fork provenance.

Acceptance tests:
GIVEN an author attempts to create an unsupported operational-coordinate field
THEN the schema rejects it and identifies the policy category.

GIVEN a scenario lacks an accessible narrative for a visual state
THEN publication is blocked.

GIVEN a published scenario is forked
THEN parent version, author, license, and modifications remain visible.

EPIC: WORKSPACES AND COLLABORATION

Roles:
- owner;
- administrator;
- author;
- analyst;
- reviewer;
- observer.

Capabilities:
- saved scenarios;
- saved runs;
- comments and annotations;
- event-targeted and proof-targeted annotations;
- assignments and resolution states;
- presenter-led replay;
- presence;
- audit history;
- export;
- configurable retention.

Public runs remain ephemeral unless explicitly saved.

Acceptance tests:
GIVEN an observer
WHEN the observer attempts to modify a scenario or annotation
THEN authorization denies the action on the server, not only in the UI.

GIVEN a user from tenant A knows an object ID in tenant B
WHEN the user requests it
THEN the response reveals no tenant-B content or metadata.

GIVEN a collaboration client disconnects and reconnects
THEN it restores the correct room, run version, presenter state, and permission scope.

EPIC: PLUGIN SDK

Plugin categories:
- renderer extension;
- scene adapter;
- importer;
- exporter;
- metric view;
- proof view;
- integration connector;
- educational module;
- simulation-engine adapter.

Manifest fields:
- plugin ID and version;
- publisher;
- license;
- compatible platform and schema versions;
- declared permissions;
- entry points;
- integrity digest;
- signature;
- network domains if any;
- data-access scope;
- accessibility declaration;
- test status;
- revocation status.

Security:
- sandbox by default;
- no network by default;
- no direct database access;
- no unrestricted DOM access;
- no secret access;
- no dynamic native code in public hosting;
- message-based APIs;
- rate and resource limits;
- signed package verification;
- kill switch and revocation.

Acceptance tests:
GIVEN an unsigned plugin
THEN production installation is denied.

GIVEN a plugin without network permission
WHEN it attempts a network request
THEN the sandbox blocks the request and records a security event.

GIVEN a plugin is revoked
THEN new loads are blocked and administrators can identify affected workspaces.

EPIC: WEBGPU AND RENDERING QUALITY

Implement:
- WebGPU enhancement path;
- WebGL2 functional fallback;
- dynamic resolution;
- quality tiers;
- instancing;
- progressive asset loading;
- KTX2 textures;
- compressed meshes;
- level of detail;
- GPU timing where available;
- frame-time monitoring;
- render suspension for hidden or static scenes;
- explicit resource disposal.

Renderer behavior must never alter authoritative simulation output.

Acceptance tests:
GIVEN WebGPU and WebGL2 runs of the same scenario
THEN canonical engine output and digest are identical.

GIVEN average frame time exceeds the selected budget
THEN optional effects or resolution reduce progressively without removing required labels,
status, or accessible information.

GIVEN a user leaves a simulation route
THEN scene resources, event listeners, animation loops, workers, and GPU allocations are released.

EPIC: ACCESSIBILITY

Target WCAG 2.2 AA and establish evidence rather than making an unsupported claim.

Required:
- semantic HTML;
- keyboard operation;
- visible focus;
- logical focus order;
- screen-reader labels and announcements;
- skip links;
- landmarks;
- reduced motion;
- forced-colors support where practical;
- 200% and 400% zoom/reflow;
- no color-only information;
- text and table parity;
- accessible errors;
- touch-target sizing;
- captions/transcripts for instructional media;
- non-XR task parity.

Supported manual matrix:
- NVDA with Firefox
- JAWS with Chrome
- VoiceOver with Safari on macOS and iOS
- TalkBack with Chrome on Android
- keyboard only
- reduced motion
- zoom/reflow
- forced colors or high-contrast evaluation

Acceptance tests:
GIVEN JavaScript is disabled
THEN simulation purpose, baseline inputs, authoritative table/text state, proof summary,
research links, and limitations remain available.

GIVEN a user operates only by keyboard
THEN the user can select a preset, edit values, execute a run, step through events, inspect
proof, compare runs, and export evidence.

GIVEN reduced motion
THEN nonessential animation, camera travel, particles, and auto-playing previews stop.

GIVEN a proof state is represented visually by color
THEN an icon, text label, and programmatic state convey the same meaning.

EPIC: PERFORMANCE

Public field targets:
- LCP <= 2.5 seconds at p75
- INP <= 200 milliseconds at p75
- CLS <= 0.1 at p75

Product budgets:
- gallery shell <= 250 KB gzip, excluding lazy simulation runtime;
- no full 3D engine on explorer route;
- accessible shell interactive <= 2 seconds on target desktop;
- first meaningful 3D frame <= 4 seconds target desktop;
- first meaningful 3D frame <= 7 seconds representative mid-tier mobile;
- sustained 60 FPS target desktop;
- minimum 30 FPS supported mobile;
- no routine main-thread task over 50 ms during interaction;
- initial common-scene payload target <= 5 MB;
- memory target <= 500 MB desktop and <= 250 MB mobile;
- deterministic lightweight API p95 <= 300 ms in primary region;
- collaboration event p95 <= 150 ms in-region.

Implement real-user monitoring using privacy-preserving buckets.
Do not log raw scenario inputs by default.

Acceptance tests:
- CI fails when public bundles exceed their budgets.
- CI fails when a representative scene exceeds frame-time budgets on the benchmark runner.
- Lighthouse CI fails on agreed threshold regression.
- A scheduled test detects unbounded memory growth across repeated route changes.
- A load test demonstrates forecast peak capacity plus an agreed safety margin.

EPIC: SECURITY

Base verification on an application security standard such as OWASP ASVS.

Implement:
- secure cookies;
- CSRF defenses where cookie authentication applies;
- strict input schemas;
- size and depth limits;
- WAF and rate limiting;
- OIDC-compatible authentication;
- MFA support;
- tenant-scoped RBAC;
- encrypted transport and managed encryption at rest;
- secrets manager;
- restrictive Content Security Policy;
- Permissions Policy;
- frame restrictions;
- signed uploads and plugins;
- malware scanning;
- immutable or append-oriented audit records;
- API-key hashing and rotation;
- HMAC webhooks with replay protection;
- SBOM;
- dependency and container scanning;
- static analysis;
- dynamic security testing;
- tenant-isolation tests;
- threat models for each major epic.

Acceptance tests:
- A cross-tenant object reference cannot disclose existence, metadata, or content.
- Malformed and deeply nested JSON is rejected before expensive processing.
- Replayed webhook deliveries are identifiable and safe.
- A plugin cannot exceed declared permissions.
- Logs and traces do not contain scenario payloads, credentials, tokens, or annotation text
  under default configuration.
- Public authoring cannot create external side effects.
- Critical and high exploitable findings block production release.

EPIC: ANALYTICS

Use a versioned event taxonomy.

Initial events:
- explorer_viewed
- explorer_filter_applied
- capability_checked
- simulation_launched
- scene_shell_ready
- first_3d_frame
- renderer_fallback_used
- preset_selected
- run_started
- run_completed
- guided_step_completed
- timeline_used
- proof_opened
- invariant_inspected
- comparison_created
- counterfactual_created
- export_created
- share_created
- collaboration_started
- annotation_created
- authoring_draft_created
- api_key_created
- plugin_installed
- accessibility_mode_selected
- simulation_error

Do not include scenario values in these events.
Provide a diagnostics screen that shows the user which telemetry category is active.

EPIC: COMMERCIAL CAPABILITIES

Free:
- public labs;
- guided modes;
- limited exports;
- public documentation.

Professional:
- saved private scenarios;
- advanced comparison;
- richer exports;
- higher API quota;
- individual authoring.

Team:
- shared workspaces;
- annotations;
- live review;
- role controls;
- embeds;
- team templates.

Enterprise:
- SSO and SCIM;
- tenant audit export;
- private plugin registry;
- configurable retention;
- private cloud or on-premises deployment;
- support and service objectives;
- optional data-residency commitments.

Usage:
- batch runs;
- parameter sweeps;
- high-volume API;
- GPU-streamed sessions.

Implement entitlements in a centralized service or policy layer.
Do not scatter plan checks across visual components.

EPIC: COMMUNITY

Build:
- public scenario gallery;
- contributor profiles;
- reproducibility badges;
- licenses;
- version history;
- forks;
- moderation;
- reporting;
- plugin registry;
- educational learning paths;
- bounded weekly challenges;
- expert walkthroughs.

Leaderboards may reward:
- proof-inspection completion;
- identification of assumptions and defeaters;
- justified abstention;
- high-quality explanations;
- reproducible scenario creation;
- peer-review contributions;
- plugin quality.

Leaderboards must not reward:
- unsafe reduction of margins;
- increased authority;
- aggressive operational performance;
- bypassing proof conditions;
- speed where speed compromises comprehension.

MILESTONE PLAN

Milestone A: Foundation and baseline, weeks 0–6
Deliver:
- architecture decision records;
- current-behavior inventory;
- golden proof and API tests;
- schema v2 draft;
- design tokens and workbench prototype;
- analytics and privacy specification;
- performance baseline;
- accessibility test plan;
- threat model;
- Simulation Explorer beta.

Exit criteria:
- all existing proof vectors run in CI;
- no-JavaScript behavior is captured;
- schema design is approved;
- explorer prototype passes keyboard and performance checks;
- one representative simulation is selected for migration.

Milestone B: Unified workbench, weeks 7–16
Deliver:
- TypeScript application shell;
- Babylon.js scene adapter;
- capability preflight;
- guided/explore/expert modes;
- shared timeline;
- proof inspector;
- baseline-versus-variant comparison;
- evidence export;
- first two or three migrated simulations;
- FastAPI sidecar and initial OpenAPI.

Exit criteria:
- migrated scenes have authoritative parity;
- all representations synchronize at every event index;
- performance budgets pass;
- required screen-reader journeys pass;
- legacy route can be restored with a feature flag;
- no critical/high security issue remains.

Milestone C: Platform and collaboration, months 5–9
Deliver:
- all ten simulations in the shared workbench;
- public API and SDKs;
- user identity and workspaces;
- annotations;
- presenter-led collaboration;
- embed kit;
- authoring beta;
- batch execution foundation;
- product analytics dashboards.

Exit criteria:
- anonymous public runs remain ephemeral;
- tenant-isolation suite passes;
- WebSocket soak test passes;
- API documentation and generated SDKs are complete;
- all ten simulations meet shared accessibility and performance gates;
- workspace audit export is available.

Milestone D: Ecosystem and enterprise, months 10–18
Deliver:
- signed plugin SDK and registry;
- community gallery;
- authoring general availability;
- parameter sweeps;
- marketplace billing;
- SSO/SCIM;
- private deployment;
- assurance copilot beta;
- optional GPU-streamed laboratory pilot.

Exit criteria:
- plugin sandbox and revocation have passed external security review;
- marketplace moderation and licensing workflows operate;
- enterprise recovery and deployment runbooks are tested;
- copilot outputs are grounded, cited, labeled, and non-authoritative;
- GPU-streaming unit economics and accessibility alternatives are documented.

REQUIRED ENGINEERING ARTIFACTS

For each epic, produce:
- architecture decision record;
- threat model;
- data-flow diagram;
- API and schema changes;
- user stories;
- acceptance tests;
- accessibility considerations;
- performance budget;
- observability plan;
- rollout and rollback strategy;
- migration plan;
- operational runbook;
- documentation and changelog;
- product analytics events;
- privacy review.

REQUIRED CI PIPELINE

Fast pull-request checks:
- formatting;
- linting;
- type checking;
- unit tests;
- schema tests;
- contract tests;
- key component accessibility tests;
- bundle budget;
- software-composition analysis.

Protected-branch checks:
- full domain proof vectors;
- API integration tests;
- Playwright critical journeys;
- no-JavaScript tests;
- visual regression;
- WebGL renderer tests;
- WebGPU tests where runners support them;
- security scanning;
- infrastructure validation.

Scheduled tests:
- multi-browser suite;
- manual-accessibility rotation;
- performance benchmarks;
- memory and GPU-resource leak tests;
- WebSocket soak;
- API load;
- batch saturation;
- dependency failure and chaos tests;
- backup restoration;
- plugin sandbox tests;
- DAST and fuzzing.

DEFINITION OF DONE

A feature is done only when:

1. The implementation is merged and deployable.
2. Domain and contract tests pass.
3. Accessibility equivalence is implemented and tested.
4. Performance budgets pass or an explicit exception is approved.
5. Security and privacy reviews are complete.
6. Analytics and observability exist without collecting prohibited content.
7. Documentation is published.
8. Feature flags and rollback procedures exist for risky changes.
9. Schema and version impacts are recorded.
10. Existing deterministic runs remain reproducible or have an explicit version migration.
11. The product clearly distinguishes representation, simulation evidence, and certification.
12. The feature cannot expand public simulations beyond synthetic, abstract,
    non-operational boundaries.

FIRST IMPLEMENTATION TASKS

Begin by producing, in order:

1. A repository and deployment inventory.
2. A current route, payload, proof-vector, and fallback matrix for all ten simulations.
3. A proposed v2 canonical schema with compatibility rules.
4. A workbench information architecture and responsive wireframes.
5. A Babylon.js versus Three.js spike using one representative scene, with bundle,
   frame-time, accessibility, and migration findings.
6. A FastAPI sidecar proof of concept wrapping one unchanged Python engine.
7. A Simulation Explorer prototype that does not load the 3D runtime.
8. A synchronized timeline prototype proving visual/table/narrative/proof parity.
9. A baseline-versus-variant comparison prototype.
10. A CI quality-gate proposal with measured current baselines.
11. A threat model for persistence, sharing, collaboration, authoring, and plugins.
12. A milestone backlog with dependencies, staffing assumptions, person-week estimates,
    risks, and explicit acceptance criteria.

When forced to choose between visual spectacle and inspectable correctness, preserve
inspectable correctness and redesign the spectacle so that it reveals rather than obscures
the causal and assurance structure.