Sonnet 5.5 vs Opus 5.5: Same Prompt, Two Models = Two Different Apps

# Build Brief: Energy Profit Twin

You are a senior product designer and full-stack engineer. Build a polished, working MVP of **Energy Profit Twin**: an operations application for energy companies that combines an interactive 3D view of an energy facility with operational data, AI-assisted investigation, scenario comparison, and a transparent financial case for taking action.

The product should help an operations or reliability team answer:

1. What is happening at the facility right now?
2. Which issue should we investigate first?
3. What evidence supports that assessment?
4. What could the proposed action change?
5. How will we verify whether it created value?

Build the application in the current project repository. First inspect the existing files, framework, scripts, and conventions. Reuse the project’s existing stack where practical. If the repository is empty, use the default stack below. Do not stop after producing a plan or static mockup: implement a navigable application with working interactions and realistic seeded data.

## Product principles

- Make the 3D facility view useful for finding and understanding operational issues. It must be linked to assets, trends, alerts, and recommended actions.
- Tie every financial estimate to visible inputs and an explainable formula.
- Label all supplied demo data and generated values as **illustrative**. Never imply that sample data represents verified customer savings.
- Keep people in control. The MVP may recommend, simulate, prepare, and track actions, but it must not operate or send commands to real equipment.
- Make the application useful on a large operations-room display, laptop, and tablet. Support mobile layouts for review and triage.
- Prefer a smaller number of complete workflows over many empty screens or decorative controls.

## Default technology choices

If there is no existing stack to preserve, build a TypeScript React application using:

- Vite for the application shell.
- React Three Fiber and Three.js for the interactive 3D facility.
- A clean component library or well-structured custom components for charts, tables, forms, drawers, and navigation.
- A typed, modular data layer with seeded demo data and local persistence for user-created demo changes.
- A simple charting library already available in the project; otherwise choose one that works well with React.

Keep the MVP runnable locally without external credentials, paid services, or live industrial-system access. If you add an LLM integration point, use a server-side adapter and environment variable for the key. The application must remain fully demonstrable without a key by using a clearly labeled deterministic demo assistant.

## Primary user roles

Include these roles in the experience, even if authentication is simulated:

- **Operations manager:** sees facility status, production or generation impact, and actions requiring attention.
- **Reliability engineer:** investigates equipment health, supporting evidence, maintenance history, and potential interventions.
- **Energy manager:** examines energy intensity, consumption, and efficiency opportunities.
- **Finance or executive viewer:** reviews estimated and verified value, assumptions, and pilot performance.
- **Administrator:** reviews data sources, data quality, and demo access settings.

Provide a simple demo role switcher. Show role-appropriate landing priorities or permissions where practical. Label this as a demonstration feature, not production authentication or authorization.

## Application navigation

Create a professional desktop layout with a left navigation rail or sidebar, a top bar, a global facility selector, a date/time range control, an alert indicator, and a user/demo-role menu.

Include these areas:

1. **Overview**
2. **3D Facility Twin**
3. **Alerts & Opportunities**
4. **Scenario Lab**
5. **Value Tracking**
6. **Data Sources & Quality**
7. **Activity Log**

Keep the navigation coherent at smaller widths. On mobile, use a compact menu and focused detail views instead of compressing the desktop layout.

## MVP workflows

### 1. Overview: understand site health at a glance

Build an executive and operations landing page with:

- Selected site name, facility type, local time, and data freshness.
- A clear overall status and counts for critical, warning, and informational alerts.
- Headline operational metrics such as production or generation, energy use, energy intensity, availability, and estimated value at risk.
- Trend cards with meaningful time ranges and units.
- “Top opportunities” ranked by estimated value, urgency, and confidence.
- Recent events and actions.
- A prominent link into the 3D twin focused on the most important active issue.

Do not invent live readings. The demo should visibly say that its readings are simulated.

### 2. 3D Facility Twin: locate and understand issues

Create an interactive, code-generated 3D model of one representative facility, such as a gas processing site with a process train, compressors, pumps, tanks, pipes, and a control building. Use Three.js geometry and materials; do not rely on a static image as the 3D experience.

The view should support:

- Orbit, pan, zoom, reset view, and selectable assets.
- A readable asset label on hover or selection.
- Status colors with a visible legend, accessible contrast, and a non-color status cue such as an icon or label.
- Filters for asset type and status.
- A focus or “fly to asset” action from an alert, opportunity, or search result.
- A details panel showing asset name, type, status, last update, key metrics, active alerts, and recent maintenance.
- Metric overlays or visual flow cues that can be toggled on or off.
- A clear fallback message if 3D rendering is unavailable, with the same asset information available in a list.

Make the initial scene visually impressive but legible. Use a restrained industrial palette, clean lighting, subtle animation only where it helps show flow or status, and avoid visual effects that make controls hard to read.

### 3. Alerts & Opportunities: prioritize investigation

Create an alert and opportunity workbench with filtering, sorting, search, and detail views.

Each item should include:

- Title, asset, severity or opportunity type, detected time, status, confidence, and estimated impact.
- A plain-language explanation of what changed.
- Supporting signals with values, timestamps, units, and trend context.
- Links to related assets, events, maintenance history, and the relevant place in the 3D twin.
- A clear distinction between observed facts, calculated estimates, and recommendations.
- Actions to assign an owner, change status, add a note, or dismiss with a reason.

Provide practical statuses such as **New**, **Investigating**, **Action planned**, **Resolved**, and **Dismissed**. Persist demo changes locally and record them in the activity log.

### 4. Scenario Lab: compare possible actions safely

Let a user open an opportunity and create a simple scenario comparing:

- Current or baseline operation.
- One or more proposed actions.
- Expected operational effect, estimated cost, downtime or risk, and projected financial effect.
- Assumptions, confidence, time horizon, and source of each input.

Provide side-by-side comparisons and a clear “illustrative estimate” label. Show the calculation details rather than only a summary score. Let users save a scenario, edit assumptions, add a note, and mark it as proposed or rejected.

The MVP does not need a high-fidelity physics simulator. Use transparent, editable scenario assumptions and clearly distinguish them from measured data.

### 5. Value Tracking: make the business case auditable

Include a value dashboard that separates:

- **Estimated opportunity value**
- **Approved or planned value**
- **Verified realized value**

For each value record, show the linked issue, asset, action, time period, calculation inputs, owner, and verification status. Allow an authorized demo role to mark an action complete and enter actual outcome values. Never automatically convert an estimate into realized savings.

Use this calculation structure, with explicit inputs and units:

- Recovered production value = recovered production quantity × net margin per unit
- Energy savings value = avoided energy use × applicable energy cost
- Avoided maintenance or downtime value = documented avoided cost, entered and verified by a user
- Net value = selected benefit categories − implementation cost

Avoid double counting. Let users select which benefit categories apply to a record and show a warning if categories may overlap. State the calculation period and annualization assumptions whenever a value is annualized.

Provide a downloadable CSV report for filtered value records and a clean, print-friendly summary view.

### 6. Data Sources & Quality: show where information comes from

Build a lightweight data-source and quality page that makes the MVP’s integration approach credible without claiming that real connectors exist.

Include:

- Example source cards for historian/SCADA, CMMS or work orders, asset registry, production or generation data, and energy pricing.
- Source status, last refresh, record count, mapped fields, and data-quality warnings.
- A demo **CSV import** flow for asset, telemetry, or maintenance data. Validate required columns, show a preview, explain rejected rows, and allow cancel before import.
- A sample CSV download or clearly documented expected schema.
- A typed connector interface or adapter layer so future real integrations can be added without coupling the UI to a specific vendor.

Do not connect to operational technology or customer systems in this MVP. Do not claim an integration is production-ready unless it actually is.

### 7. AI Operations Assistant: grounded, useful, and cautious

Add an assistant panel that can answer questions about the seeded site and imported demo data, such as:

- “What changed on this compressor?”
- “Which open issue has the highest estimated value?”
- “What evidence supports this opportunity?”
- “Compare the two proposed actions.”
- “Summarize the last shift’s important events.”

The assistant must:

- Use only data available in the application or explicitly provided demo reference material.
- Cite the records, readings, events, or assumptions used in each answer, linking back to them in the UI.
- Say when the data is missing, stale, contradictory, or insufficient.
- Separate facts from estimates and recommendations.
- Never fabricate measurements, savings, work orders, or causal explanations.
- Never present itself as an autonomous operator or safety authority.
- Provide a deterministic demo mode when no model API is configured. In demo mode, clearly label responses as scripted or rule-based.
- Keep secrets and model credentials out of browser code and local storage.

### 8. Activity Log: make changes reviewable

Record user actions such as assignment, status changes, comments, scenario edits, value verification, and data imports.

Each entry should show actor/demo role, timestamp, action, affected record, and relevant before/after values. Provide basic filters and search. This is an application activity log for the MVP, not a claim of a compliant or tamper-proof audit system.

## Demo scenario and seeded data

Seed a fictional site named **Cypress Ridge Gas Processing Plant**. Make it clear in the interface that the site and all values are synthetic demonstration data.

Include a small, internally consistent set of assets, such as:

- Compressor CR-204
- Pump P-118
- Gas turbine GT-01
- Separator SEP-03
- Cooling system CW-02
- Connected process lines and storage equipment

Include enough synthetic time-series readings, events, alerts, and work-order history to demonstrate filtering, trends, data provenance, and the assistant. Add one main story: a compressor whose energy intensity has increased while throughput has decreased, creating an investigation opportunity. Include at least one unrelated alert, one maintenance-history clue, and two proposed actions with different assumptions so the scenario comparison is meaningful.

Make all dates relative to a fixed demo dataset date or the system date consistently. Give every reading a unit, timestamp, asset ID, and source. Do not use implausibly precise data or imply these values represent actual industry performance.

## Visual and interaction design

Aim for a polished industrial operations product suitable for a CIO demo:

- Clear typography, strong hierarchy, generous spacing, and a restrained dark navy/charcoal interface with bright but sparing status accents.
- A consistent design system for buttons, filters, tables, metric cards, drawers, dialogs, tooltips, and empty/error states.
- High-quality loading, empty, validation, and failure states.
- Charts with readable labels, units, legends, and accessible tooltips.
- Keyboard-accessible navigation and controls; visible focus states; labels that do not rely on color alone.
- Useful confirmation for destructive actions and clear success/error feedback for user actions.
- No lorem ipsum, dead buttons, placeholder cards, or controls that look interactive but do nothing.

Use sensible animation for navigation and 3D interaction, but respect reduced-motion preferences.

## Data model and implementation quality

Define typed models for at least:

- Site
- Asset
- TelemetryReading
- Alert or Opportunity
- MaintenanceRecord
- Scenario
- ValueRecord
- DataSource
- ActivityEvent
- AssistantMessage and its evidence references

Keep calculations and business rules in tested utility functions, separate from presentation components. Include realistic loading and error handling even when data is local. Use local storage only for demo preferences and user-created demo changes; include a reset-demo-data action.

Add a concise README with setup instructions, environment variables, demo limitations, CSV schemas, and a short guided demo flow.

## Acceptance criteria

The MVP is complete when a user can:

1. Start the app locally using the README instructions.
2. Explore the overview and understand that the dataset is synthetic.
3. Navigate the 3D model, select an asset, and open the related asset details.
4. Open the compressor opportunity from the dashboard or alert list and trace it to evidence.
5. Compare two editable proposed actions in the Scenario Lab.
6. Assign the opportunity, change its status, add a note, and see those changes in the activity log.
7. Review an estimated value, inspect its inputs, and record an actual outcome without treating the estimate as verified savings.
8. Import a valid sample CSV, see validation feedback, and use the imported data or see exactly why rows were rejected.
9. Ask a supported assistant question and receive an answer with clickable evidence—or receive a clear “not enough data” response.
10. Use the main workflows on desktop and a narrow mobile viewport without clipped or inaccessible controls.

Before finishing, run the available build, type-check, and tests. Fix errors that block the app or its core workflows. In your final response, summarize what you implemented, how to run it, what is demo-only, and what verification you completed.