Play First, Authenticate Later

One of the most useful lessons from building Incident Arcade had nothing to do with AWS, detection logic, or scoring.

It was about authentication.

Incident Arcade was designed as a public training application. Someone should be able to discover it, open a case, investigate the activity, make a decision, and understand what the application offers without creating an account first.

Then we integrated SATIE.

SATIE is a different kind of application. It is an authenticated analyst environment with a different trust boundary. Connecting the Arcade to it made sense, but our first implementation pushed that authentication boundary too far toward the public experience.

The result was exactly what you would expect.

A casual Arcade visitor could click Open in SATIE, get redirected into HDJames authentication, hit a permission boundary, and suddenly find themselves stranded away from the case they had been investigating.

At one point the integration went even further and effectively made authentication part of the Arcade experience itself.

That was the wrong product model.

The correct model is simple:

Play first. Authenticate when authenticated value is actually requested.

Incident Arcade remains public.

SATIE remains protected.

A player should be able to complete a full Arcade case anonymously. Local progression can preserve XP, streaks, mastery, and records without requiring identity.

Authentication only becomes relevant when the player deliberately asks for something that requires it.

That distinction changes the user experience completely.

Instead of:

Visit → Sign Up → Maybe Discover Value

the flow becomes:

Visit → Play → Understand Value → Choose Whether to Sign In

That also changed how we think about cross-application navigation.

Browser Back is not a recovery strategy.

Before crossing from the public Arcade into an authenticated environment, the current case needs to be preserved. Authentication cancellation, session expiration, or permission denial must have an explicit path back. Mobile browsers make that even more important because tabs and authentication redirects do not always behave like their desktop equivalents.

The principle now is:

Persist → Navigate → Return → Restore.

And there is another important lesson.

An unauthenticated visitor should not have to discover that SATIE requires authentication by failing into a permission screen.

Explain the boundary first.

SATIE should be presented as an optional advanced analyst workstation. If the user wants it, authenticate. If not, dismiss the explanation and keep investigating the current Arcade case.

Public applications and authenticated applications can work together.

They just should not pretend they have the same trust boundary.