← MARTINEZ AI STUDIOS 2.0
VERIFIED INTERNAL EVIDENCE

Proof before promises.

This library connects Studio 2.0 positioning to real production work. Every published case comes from an internal CONTRABAND incident documented with root cause, fix, validation and public-safe evidence.

Disclosure: these are Martinez AI Studios internal cases, not customer testimonials or client results. They are not presented as proof of every Studio 2.0 offer.

01 / WHAT THE METHOD DEMONSTRATES
01

Source-linked diagnosis

The case separates symptom, impact, reproduction, system ownership and root cause.

02

Minimal correction

The solution is described by the necessary change, not by code volume or tool count.

03

Regression protection

Validation leaves a concrete way to check that the same failure does not silently return.

04

Reusable lesson

Each incident ends in a rule that can transfer to future systems, agents and pipelines.

02 / PUBLISHED CASES

5 incidents. Real evidence.

This collection brings together published internal cases supported by evidence. Each links to the complete analysis in Academy.

01VERIFIEDState ownership

Keros arrival distance: two paths, two positions

Last Run taught a real Keros ↔ Belu warp. The return jump did not share the scripted near-dock pose.

GENERALIZED LESSON

System id is not pose. Two entry paths that share a label still need a shared placement contract. Mixing local and world spaces looks like a “warp bug” to the player and like a one-line vector add to an AI assistant. Own one arrival policy per intent (vista vs near-dock) and test metres, not only flags.

EVIDENCE (3)
  • CONTRABAND development log, 19 Aug 2026, v0.4.155–v0.4.157 (Keros near-dock / second jump).
  • last-run-map-warps.test.mjs (dock metres, two arrival paths, map completion rules).
  • last-run-map-lesson.js comments and lastRunSecondKerosArrivalUsesNearDock; galaxy-arrival trusted dock samples.
READ FULL CASE →
02VERIFIEDInput & UX

Pointer lock vs clickable dialogue

Flight wants the mouse captured. Choice buttons 1/2 need the mouse free. Those states collided in Last Run.

GENERALIZED LESSON

Capture modes are exclusive with clickable overlays. Own the transition: exit lock, tell the player how, and do not bind ESC to two verbs. Device-specific UI (hide the hint on gamepad) is part of correctness, not polish.

EVIDENCE (3)
  • CONTRABAND development log, 19 Aug 2026, v0.4.148–v0.4.153 (ESC hint / recapture).
  • lastRunShouldShowReleaseMouseHint; pointer-lock-policy.js story vs live combat.
  • last-run-from-verge.test.mjs
READ FULL CASE →
03VERIFIEDRendering

WebGL context lifecycle: dispose is not free

Shipyard, lock hologram, 3D map, hangar, and inventory each opened a GPU context. The flight canvas paid the bill.

GENERALIZED LESSON

GPU contexts are a shared budget, not a private field on a component. Lifecycle is pause vs destroy. An AI that “cleans up” with dispose() on every React-like unmount can take down the game view. Count live renderers; test reopen loops, not a single open.

EVIDENCE (3)
  • webgl-preview-pool.js header comment and acquire/pause/destroy API.
  • CONTRABAND development log, 19 Aug 2026, v0.4.158; earlier white-canvas / shipyard churn notes.
  • webgl-preview-lifecycle.test.mjs
READ FULL CASE →
04VERIFIEDSystems & economy

Survival progression: threshold, duplicates, difficulty

Hull unlocks, kill pay, and ten difficulty profiles had to stay independent contracts.

GENERALIZED LESSON

Economy fields need names for each consumer (shop vs unlock vs repair). Shared += on credits is how duplicate rewards happen. Difficulty, loot, and progression are three knobs; coupling them in a prompt will “balance” the wrong one.

EVIDENCE (3)
  • CONTRABAND development log, 20 Aug 2026, v0.4.159.
  • survival-progression-rewards.test.mjs
  • ships.js survivalProgressionPrice vs price; survival-progression.js; combat.js isKaelaSurvivalKill.
READ FULL CASE →
05VERIFIEDRelease engineering

Release gates: QA, cloud, then a build

A Steam App ID on the store is not a substitute for a local gate that can fail.

GENERALIZED LESSON

Shipping is a checklist that can fail, not a screenshot of the store. Encode language, input, and persistence as cells. Never put Steamworks admin identity in educational write-ups. AI that “just uploads the build” skips the only tests that catch Last Run and cloud ordering.

EVIDENCE (3)
  • package.json scripts qa:release and qa:release:logic (unit + story-graph + validate-release + Electron QA).
  • CONTRABAND development log, 15 Aug 2026, v0.4.89–v0.4.91.
  • play/systems/steam-cloud.js (public behavior only: named save file, debounce, backup).
READ FULL CASE →
03 / ACADEMY × STUDIO 2.0

The same evidence can teach and show how we work.

Academy preserves the complete technical case. Studio 2.0 uses that evidence layer so a buyer can distinguish a commercial promise from a documented production practice.

EXPLORE ACADEMY CASES →
04 / NEXT STEP

Bring one hard workflow. Start with what can be verified.

For game production or creative systems, we can start with one bounded problem, define evidence and acceptance criteria, and build from there.

DESCRIBE THE PROJECT →
READING AND APPLICATION GUIDE

Read an incident as a chain of evidence.

A useful case explains what failed, why the explanation fits the observations and how the fix was checked. Before borrowing a lesson, identify its scope: a rendering fix proves something about that rendering path, not every capability offered by the studio. The linked Academy cases preserve the longer technical analyses.

Reading exercise: a visual symptom can have a state cause

Imagine a fictional quest reward appearing twice after loading a saved game. A screenshot confirms the symptom, but not the cause. The investigation needs a repeatable sequence, the saved state before and after, and the code path responsible for granting the reward. Changing the visible text would not establish that the state was fixed.

A useful report separates the observation from the hypothesis, records the minimal correction and repeats the sequence with neighboring cases. That same reading method applies to the internal incidents listed here. The example above is explanatory; the linked case pages are the source for what actually happened in CONTRABAND.

Practical criteria for reviewing the example
EvidenceQuestion to askWhat it does not prove
ReproductionCan another person trigger the same failure from the stated starting point?A screenshot alone does not identify the responsible subsystem.
CorrectionDoes the change address the cause and preserve the surrounding behavior?More code or a different tool does not establish correctness.
Regression checkDoes the check fail before the fix and pass after it?One passing case does not cover all devices, states or future changes.

An exercise for your project

  1. Open one Academy incident and summarize the symptom and starting conditions without reading its solution first.
  2. Compare your hypothesis with the documented cause. Identify the evidence that distinguishes them.
  3. Write one neighboring case that could still fail, and describe the observation you would need to test it.

Concepts worth distinguishing

Root cause
The mechanism that explains the observed failure and is addressed by the correction.
Regression
Previously working behavior that breaks after a change; preservation must be checked at the behavior and content levels.
Evidence boundary
The precise conditions a result supports, including what remains untested.