Probability Director Runtime Inspector

The Probability Director Runtime Inspector is Probability Director’s read-only developer window for examining live Runtime state during PIE or an eligible game preview.

Open it from:

Tools → Director Suite → Runtime Inspectors → Probability Director Runtime Inspector

Use the Inspector when you need to answer questions such as:

Which Probability Director Streams exist in this GameInstance?
Is this Stream Sequential or Keyed?
Is it Fixed or Secure?
Did this operation actually advance Sequential RNG state?
What result did a recent supported random operation return?
Why are repeated requests being rejected?
Did a persistence operation fail or become stale?
Which Decision Key was used for this Keyed operation?
Can I capture the current diagnostic state before PIE ends?
Can I export a safe snapshot for debugging without exposing RNG secrets?

The Inspector is observational.

It does not roll, sample, reset, reseed, rewind, or otherwise change Probability Director gameplay state.

1. What the Inspector Is For

Think of the Inspector as a developer window into the current Probability Director subsystem.

GameInstance
    |
    +--> Probability Director Subsystem
            |
            +--> Registered Streams
            +--> Diagnostic Events
            +--> Warnings
            +--> Sanitized Stream/Decision metadata
                    |
                    v
          Probability Director Runtime Inspector

The Inspector helps answer:

What is Probability Director doing in this Runtime Context?

It does not answer:

What should my game do with this result?

Gameplay meaning remains owned by your game.

2. When to Use It

Use the Inspector when:

A Stream cannot be found.
A Sequential result seems to repeat unexpectedly.
A Keyed result changes when you expected it to stay stable.
A Keyed result repeats and you want to confirm why.
A save/restore operation is being rejected.
You want to confirm which Seed Source and Decision Mode a Stream actually uses.
You want to inspect recent supported generated values.
You want to compare multiple PIE GameInstance contexts.
You want a safe exported snapshot for a bug report.
You need to examine state after a problem occurs without stopping gameplay immediately.

You normally do not need the Inspector for ordinary gameplay logic.

3. Inspector vs. Developer Labs

The Inspector and the Developer Labs solve different problems.

Tool	Main question
Dice / Probability / Distribution Labs	“What should this probability system do, and what do samples look like?”
Lab Samples	“What is the isolated experiment producing?”
Probability Director Runtime Inspector	“What Streams, operations, statuses, warnings, and sanitized decision details exist in this Runtime Context?”

Example:

Dice Lab
    -> Roll Dice
    -> Result = 17

Probability Director Runtime Inspector
    -> shows the Stream
    -> may show the retained operation
    -> shows whether Sequential state Advanced
    -> may show Generated Value = 17

The Lab performs the action.

The Inspector observes retained diagnostic information about Runtime behavior.

4. Runtime Contexts

Probability Director is GameInstance-scoped.

The Inspector therefore requires an explicit Runtime Context.

In PIE, more than one context may exist.

Example:

PIE Player 1
    -> GameInstance A
    -> Probability Director A

PIE Player 2
    -> GameInstance B
    -> Probability Director B

Those subsystems are isolated.

A Stream named:

Combat.Damage

can exist in both contexts and still represent two independent Runtime Streams.

4.1 Why Context Selection Matters

Suppose your Blueprint says:

Has Stream: Combat.Damage
    -> True

but the Inspector does not show Combat.Damage.

Before assuming Probability Director lost the Stream, verify that the Inspector is looking at the same GameInstance.

A common debugging mistake is inspecting:

PIE Client 1

while the operation occurred in:

PIE Server

or another PIE instance.

4.2 Example: Multiple PIE Instances

If you are testing two players:

Runtime Context:
PIE_0

may show:

Combat.Damage
Loot.Player1

while:

Runtime Context:
PIE_1

may show:

Combat.Damage
Loot.Player2

This is expected.

The Inspector never merges multiple GameInstance registries into one fake global Stream list.

5. Main Inspector Layout

The Inspector is organized around:

Runtime Context controls.
Streams.
Selected Stream Details.
Recent Decisions.
Events.
Warnings.
Freeze / Resume.
Diagnostics controls.
Export.

At normal width, Selected Stream Details and Recent Decisions appear side-by-side.

At narrow widths, they stack vertically.

6. Streams

The Streams table shows Streams registered in the selected Runtime Context.

The main Stream list focuses on the important identity/configuration fields:

Stream ID.
Seed Source.
Decision Mode.
Persistence Policy.

Selecting a row opens detailed information below it.

6.1 Why Look at the Streams Table?

Use the Streams table to confirm Runtime configuration rather than relying on what you think was created.

Example:

You expected:

Stream:
Loot.DropTable

Seed Source:
Fixed

Decision Mode:
Keyed

but the Inspector shows:

Seed Source:
Secure

Decision Mode:
Sequential

That immediately tells you the problem is configuration/lifecycle, not the probability operation itself.

7. Stream ID

A Stream ID is the semantic identity of a registered Probability Director Stream.

Examples:

Combat.Damage
Combat.Critical
Loot.DropTable
World.Encounters
NPC.Names

Use stable semantic IDs.

Do not expect the Inspector to infer that two different IDs were “supposed to mean the same thing.”

Example:

Loot.DropTable

and:

Loot.DropTables

are different Stream IDs.

8. Seed Source

The Inspector identifies the Stream’s Seed Source.

Typical values:

Fixed.
Secure.

8.1 Fixed

Fixed means the Stream was configured from reproducible Fixed-Seed input.

The Inspector identifies the Stream as Fixed but does not display the Fixed Seed value.

Why?

Because the Inspector’s purpose is to expose safe Runtime diagnostics, not to become a general secret/state extraction surface.

If you need the authored Fixed Seed, inspect the configuration source that created the Stream.

8.2 Secure

Secure means the Stream was initialized through Probability Director’s Secure random architecture.

The Inspector may show safe implementation identity such as:

Secure Entropy Source.
Secure Entropy Version.

It does not expose:

Secure root.
Entropy bytes.
Key.
Nonce.
Raw RNG state.

Knowing the implementation identity does not make the Secure run reproducible.

9. Decision Mode

A Stream is normally:

Sequential, or
Keyed.

This is one of the first fields to check when a result behaves unexpectedly.

9.1 Sequential

Sequential means:

Give me the next result from this Stream.

Call order matters.

Example:

Combat.Damage
    -> Roll A
    -> Roll B
    -> Roll C

Adding another Sequential call before Roll B can change all later results.

9.2 Keyed

Keyed means:

Give me the result for this explicit semantic decision.

A Keyed operation depends on the approved Decision Key contract rather than a persistent Sequential cursor.

Example:

Namespace:
Loot

Stable Subject ID:
Chest.Region3.0042

Decision:
Rarity

Occurrence:
0

Repeating the same compatible request intentionally repeats the same deterministic coordinate.

10. Persistence Policy

The Stream list also shows Persistence Policy.

This tells you whether/how the Stream participates in Probability Director persistence.

Do not confuse Persistence Policy with Decision Mode.

A Stream can be:

Sequential + Ephemeral

or:

Sequential + persisted policy

depending on the configured design.

11. Selected Stream Details

Selecting a Stream opens Selected Stream Details.

This section provides a read-only deterministic-contract summary for that Stream.

It can include:

Seed Source.
Decision Mode.
Persistence Policy.
Generator Algorithm.
Generator Version.
Seed Derivation Version.
Keyed Derivation Version.
Canonical Encoding Version.

Secure Streams additionally show:

Secure Entropy Source.
Secure Entropy Version.

12. Why Deterministic Contract Metadata Matters

Suppose a Fixed or Keyed result changes after a major plugin upgrade.

You may want to know whether the deterministic implementation contract changed.

The Inspector can show identity metadata such as:

Generator Algorithm:
ProbabilityDirector.ChaCha20IETF

Generator Version:
1

Seed Derivation Version:
1

Keyed Derivation Version:
1

Canonical Encoding Version:
1

This helps answer:

Am I still running the deterministic contract I expected?

It does not expose the Stream’s reconstructable state.

13. What Selected Stream Details Do Not Show

Selected Stream Details intentionally do not expose:

Fixed Seed value.
Secure root.
Entropy bytes.
Raw generator state.
Key.
Nonce.
Byte position.
State fingerprint.
Lifetime numeric Sequential cursor.
Internal persistence secrets.

This is a deliberate public safety boundary.

14. Recent Decisions

Recent Decisions is a filtered projection of the selected Stream’s retained diagnostic Events.

It is not a second history buffer.

It is not a complete lifetime log.

It is not guaranteed to contain every operation.

Rows can include:

Sequence.
Operation.
Mode.
Sequential Effect.
Status.
Value.
Decision indicator.

Lifecycle operations such as:

CreateStream.
RemoveStream.

are excluded from Recent Decisions.

15. Why Use Recent Decisions?

Recent Decisions is useful when you want to inspect one Stream without searching the entire global Events table.

Example:

Your game contains:

Combat.Damage
Combat.Critical
Loot.DropTable
AI.Decisions

The Events table may contain activity from all of them.

Selecting:

Combat.Damage

lets Recent Decisions focus on retained operations for that Stream.

16. Status

The Inspector shows a readable Status separately from the raw diagnostic Result.

Examples:

Success

Failure - StreamRuntime (2)

The raw domain/code remains available in:

Tooltips.
Details.
Structured export.

16.1 Why Status and Value Are Separate

Suppose an operation returned:

Zero may be a perfectly valid result.

If failure and output were displayed in one ambiguous field, a developer could mistake:

for:

no result

The Inspector therefore keeps:

Status

and:

Generated Value

separate.

The same applies to:

false

for Boolean results.

17. Generated Value

Supported retained random operations may include an approved bounded generated scalar value.

Examples:

false

0.342817

Current supported scalar categories include:

Boolean.
Signed Integer.
Unsigned Integer.
Floating Point.

Numeric Dice may retain:

Final numeric outcome, or
Success Count.

Supported scalar distributions may retain their returned scalar sample.

18. Why Some Operations Say “Not Captured”

Not every Runtime output is safe or useful to retain generically.

Current unsupported examples include:

Arbitrary Name-generation output.
Arbitrary text.
Coin-specific output families not individually approved for this event contract.
Weighted payloads.
Composite result structs.
UObject/gameplay-object data.
Full Dice trace/provenance.

For those operations, Decision Details may show:

Generated Value:
Not captured for this operation

This does not mean the operation failed.

It means that output type is not part of the approved bounded diagnostic value contract.

19. Decision Details

Selecting a Recent Decision opens Decision Details.

It repeats important context such as:

Sequence.
Operation.
Mode.
Sequential Effect.
Status.
Generated Value.

For Keyed operations it can also show:

Namespace.
Stable Subject ID.
Decision.
Occurrence.
Key Schema Version.

20. Example: Why Did This Keyed Result Repeat?

Suppose gameplay calls:

Namespace:
Loot

Stable Subject ID:
Chest.0042

Decision:
Rarity

Occurrence:
0

twice.

Both calls return:

Epic

or the same numeric sample.

Open Recent Decisions and inspect the Keyed metadata.

If both rows show the same:

Namespace
Stable Subject ID
Decision
Occurrence

then deterministic repetition is expected.

To request another semantic occurrence, your caller must deliberately change:

Occurrence

or another part of the decision identity.

The Inspector is useful here because it shows what Keyed identity Runtime actually received.

21. Example: Why Did My Keyed Result Change?

Suppose you expected the same result, but Recent Decisions shows:

Occurrence: 0

for one call and:

Occurrence: 1

for the next.

The Stream is behaving correctly.

The caller changed the deterministic coordinate.

Another common cause is a changed:

Namespace.
Stable Subject ID.
Decision.

Use Decision Details to compare the actual retained sanitized fields.

22. Stable Subject ID Truncation

Diagnostic StableSubjectId is bounded.

If the authored identity exceeds the diagnostic retention limit, the Inspector marks it as truncated.

This means:

The Runtime Decision Key may have been longer than the safe diagnostic copy shown here.

Do not assume the truncated diagnostic string was the full Runtime key.

23. Sequential Effect

Sequential Effect tells you whether the operation actually consumed Sequential generator state.

Values:

Display	Meaning
Advanced	The operation consumed Sequential random bytes
Did Not Advance	The operation consumed no Sequential random bytes
Not Applicable	The event is not a Sequential random operation

24. Why Sequential Effect Is Useful

A common assumption is:

Every successful random operation advances the Stream.

That is not always true.

Example:

A deterministic bound-one operation may have exactly one possible choice.

Probability Director may return the correct result without consuming random bytes.

Recent Decisions can show:

Status:
Success

Sequential Effect:
Did Not Advance

That is not automatically an error.

It tells you the operation did not require Sequential random consumption.

25. Sequential Effect Is Not a Position

Advanced does not mean:

Stream position = 42

The Inspector does not expose:

Numeric call index.
Byte cursor.
Generator position.
Lifetime advance counter.

It only exposes the semantic effect of the individual retained operation.

26. Example: “My Next Roll Did Not Change”

Suppose you expected:

Roll A
Roll B

to consume two distinct Sequential decisions.

Recent Decisions shows:

Roll A
Sequential Effect: Did Not Advance

Roll B
Sequential Effect: Advanced

Now you know Roll A did not consume Sequential state.

The next investigation should be the operation’s configuration.

Possible legitimate reasons include:

Only one possible outcome.
Deterministic endpoint.
Bound-one selection.
Validation path that returned without random work.

Do not infer a Runtime defect solely from repeated output.

27. Events

The Events table shows retained diagnostic events for the selected Runtime Context.

Unlike Recent Decisions, Events can include broader operation types.

Use it when you need to inspect:

Lifecycle operations.
Random operations across multiple Streams.
Persistence operations.
Failures.
Status chronology.

28. Event Status

The human-facing result column is:

Status

Successful events show:

Success

Failures show a readable form such as:

Failure - StreamRuntime (2)

The lower-level diagnostic Result remains available in detailed views/exports.

29. Persistence Generation

Some events can display Persistence Generation.

When no persisted Stream-state generation applies, the Inspector shows:

N/A

This includes Ephemeral Streams.

A numeric Persistence Generation means persisted Stream-state generation only.

It is not:

Random-call count.
Sequential position.
Lifecycle epoch.
Number of rolls.
Keyed occurrence.

30. Example: Do Not Use Persistence Generation as RNG Position

Suppose you see:

Persistence Generation:
3

That does not mean:

This was the third random call.

It means the event refers to persisted Stream state associated with persistence generation 3.

Use Sequential Effect to understand whether one retained operation advanced Sequential RNG state.

There is no public numeric Sequential cursor in the Inspector.

31. Warnings

The Warnings section summarizes repeated or suspicious Runtime conditions.

Examples include:

Repeated invalid Stream requests.
Repeated invalid Decision Keys.
Repeated numerical failures.
Repeated sampling-limit failures.
Stale RotateOnSave commits.
Repeated restore rejection.
Repeated BeginNewCampaign.

Warnings are diagnostic signals, not automatic proof of a plugin defect.

32. Example: Repeated Invalid Stream Request

Suppose Warnings shows:

RepeatedInvalidStreamRequest

Check:

Was the Stream created?
Is the Stream ID spelled exactly the same?
Did the operation happen before Create Stream?
Was the Stream removed?
Are you inspecting the correct Runtime Context?

Example bad ordering:

BeginPlay
    -> Sample Combat.Damage
    -> Create Combat.Damage

Correct:

BeginPlay
    -> Create Combat.Damage
    -> Sample Combat.Damage

33. Example: Repeated Invalid Decision Key

Suppose:

RepeatedInvalidDecisionKey

appears.

Check:

Namespace.
Stable Subject ID.
Decision.
Occurrence.
Expected schema version.
Stream Decision Mode.

If the Stream is Sequential but the caller tries to use a Keyed API, fix the caller rather than changing the warning threshold.

34. Example: Repeated Sampling Limit Failure

This warning means a bounded sampling/work limit was repeatedly reached.

It can occur legitimately in stress tests.

Do not “fix” it by blindly making the algorithm unbounded.

Instead:

Inspect parameters.
Inspect native operation status.
Determine whether the configuration is realistic.
Check whether caller code is automatically repeating the same failing request.

35. Strict Read-only boundary

The Probability Director Runtime Inspector only observes copied runtime data. It does not clear retained diagnostics, change diagnostic capture settings, or modify stream configuration, random state, or persistence state.

To enable or disable future successful-operation capture, use Probability Director Runtime Controls. To clear retained event and warning history, use the same Controls surface and review its stated consequence before acting.

36. Read-only Inspector actions

Context selection, Freeze View, Resume Live, Refresh, filtering, sorting, detail selection, copy, and export change only the Inspector’s view or exported data. They do not mutate the observed Probability Director subsystem.

41. Refresh

Refresh updates the Inspector from the selected live Runtime Context.

Use Refresh when:

A new Stream was just created.
A Stream was removed.
A warning just occurred.
You want the latest Events/Recent Decisions immediately.

The Inspector also uses lightweight periodic refresh while visible.

42. Why Refresh Is Read-Only

Refresh does not:

Recreate Streams.
Restart diagnostics.
Reset RNG state.
Re-run operations.
Change persistence.

It only updates the copied Inspector presentation from current Runtime diagnostic/state information.

43. Clearing diagnostic history

The Inspector does not provide a clear-history command. To remove retained events and warnings for a context, open Probability Director Runtime Controls. That operation does not alter registered streams, random state, configuration, persistence, or gameplay state.

45. Freeze View

Freeze View captures the current pointer-free Inspector presentation.

While frozen, the status reads:

FROZEN VIEW — Captured at <time>

followed by:

Gameplay and Probability Director continue running normally.

Freeze affects only what the Inspector displays.

46. Freeze Does Not Pause Gameplay

Freeze View does not pause:

PIE.
Gameplay.
Probability Director.
Runtime Streams.
Diagnostic collection.

It freezes only the copied Inspector view.

This distinction is important.

47. Why Use Freeze View?

Use Freeze when:

A failure just happened and you want to preserve the visible state.
PIE is about to stop.
A Stream is about to be removed.
You want to compare the captured state with later live activity.
You want to export exactly what you saw at the moment of failure.
You are debugging teardown/lifecycle behavior.

48. Example: Capturing a Problem Before PIE Ends

Suppose a save operation fails only during level shutdown.

Workflow:

1. Reproduce failure
2. Open/select correct Runtime Context
3. Freeze View
4. End PIE
5. Continue inspecting frozen Streams/Events/Warnings
6. Export the frozen snapshot

Because the frozen view is pointer-free, it can remain inspectable after the originating PIE context ends.

49. What Is Disabled While Frozen?

While frozen:

Runtime Context switching is disabled.
Refresh is disabled.
Runtime Context switching is disabled.
Refresh is disabled.

Still available:

Filtering.
Sorting.
Warning details.
Selected Stream Details.
Recent Decisions.
Decision Details.
Export of copied frozen data.

50. Resume Live

Resume Live discards the frozen presentation and returns to current live Runtime data.

If the original context no longer exists, the Inspector transitions to the appropriate no-context/live-context state instead of dereferencing destroyed Runtime objects.

51. Filtering and Search

Streams, Events, Warnings, and Recent Decisions support safe filtering/search/sorting as appropriate.

Use filters to reduce noise.

Example:

If Events contain hundreds of records, filter for:

Combat.Damage

or:

Failure

rather than exporting everything first.

Filtering changes the presentation only.

It does not delete Runtime diagnostic data.

52. Bounded Retention

Diagnostics history is bounded.

Older rows eventually disappear when capacity is reached.

Default Development/Editor capacities are:

Events:   256
Warnings: 128

Recent Decisions uses the same bounded Events history.

It is not a second unlimited history.

53. Why an Old Decision May Disappear

Suppose you enabled successful-operation capture and generated 1,000 operations.

The Events capacity is bounded.

An early retained decision may no longer exist.

That does not mean:

Probability Director forgot the gameplay state.

It means:

The diagnostic record was evicted from the bounded observation history.

Gameplay Stream state and diagnostic history are different things.

54. Export

The Inspector supports two export scopes:

Export Current View
Export Full Snapshot

55. Export Current View

Use Export Current View when you want the currently selected/filtered/sorted presentation.

Example:

Filter Events:
Status contains Failure

Sort:
Newest first

Export Current View

This is useful for a focused bug report.

56. Export Full Snapshot

Use Export Full Snapshot when you want the complete copied diagnostic snapshot for the selected Runtime Context.

This is useful when:

Sending a complete internal diagnostic package.
Preserving context before teardown.
Reviewing several sections later.
Avoiding accidental omission from filters.

57. Export Formats

Supported Inspector export formats include:

CSV.
Markdown.
JSON.
PNG where appropriate.
Multi-file report bundle.

Structured exports preserve approved redacted fields.

58. Recent Decision Export

Recent Decision structured export can include:

Status.
Raw diagnostic Result.
Mode.
Sequential Effect.
Sanitized Decision Key metadata.
Generated Value type.
Generated Value.
Generated-value truncation metadata.

JSON uses a typed:

"generatedValue": { ... }

or:

"generatedValue": null

when no approved generated output exists.

59. Example: Exporting a Keyed Bug Report

Suppose a Keyed loot result differs unexpectedly.

Recommended workflow:

1. Select correct Runtime Context
2. Select Loot Stream
3. Enable Record Successful Operations in Runtime Controls if needed
4. Reproduce the call
5. Select the Recent Decision
6. Verify Namespace / Subject / Decision / Occurrence
7. Freeze View
8. Export Current View or Full Snapshot

The resulting report can show the semantic key and status without exposing raw RNG secret state.

60. Open Project Logs

Open Project Logs opens Unreal’s normal project log directory.

This is separate from Inspector export.

Probability Director diagnostics are retained in memory and are not automatically mirrored into a dedicated Probability Director diagnostic log file.

Use:

Inspector Export for structured Inspector state.
Project Logs for normal Unreal logging.

61. Security and Redaction

The Inspector exposes enough information to diagnose behavior without exposing reconstructable RNG internals.

Approved/safe concepts include:

Stream ID.
Seed Source identity.
Decision Mode.
Persistence Policy.
Generator/version identity.
Derivation/encoding version identity.
Sanitized Decision Key fields.
Status.
Semantic Sequential Effect.
Approved generated scalar values.

62. Never Exposed

The Inspector does not display/export:

Secure root.
Secure seed material.
Entropy bytes.
Generator key.
Generator nonce.
Raw ChaCha state.
Numeric byte position.
Numeric Sequential cursor.
State fingerprint.
Arbitrary gameplay payloads.
Gameplay-object references.
Raw persistence secrets.
Unsanitized arbitrary Decision Key payloads.

Fixed Seed is also redacted from Inspector diagnostic views.

63. Example: Secure Stream Details

A Secure Stream may show:

Seed Source:
Secure

Generator:
ProbabilityDirector.ChaCha20IETF

Generator Version:
1

Secure Entropy Source:
ProbabilityDirector.SecureRandomBytes

Secure Entropy Version:
1

This tells you:

Which approved implementation contract is active.

It does not tell you:

What random secret material initialized this Stream.

64. Inspector Does Not Reset Streams

There is intentionally no:

Reset Stream

button in the Inspector.

The Inspector is read-only with respect to gameplay random state.

If your game needs to remove/recreate/reset state, use the appropriate Runtime API through gameplay-owned logic.

Do not use developer diagnostics as gameplay control.

65. Inspector Does Not Create Streams

If a required Stream is missing:

Inspector:
Combat.Damage not present

the correct fix is not:

Have the Inspector create it.

Instead investigate the caller responsible for:

Create Stream

The Inspector should reveal lifecycle mistakes, not hide them.

66. Inspector Does Not Reproduce Secure Streams

The Inspector can identify Secure configuration and implementation versions.

It intentionally cannot reconstruct a Secure sequence.

If you need reproducible debugging:

Use an intentionally configured Fixed Stream, or
Use a Keyed deterministic workflow where appropriate.

67. Common Troubleshooting Workflows

A. Stream Is Missing

1. Select correct Runtime Context
2. Search Streams for expected Stream ID
3. If missing, inspect Events for creation/removal/failure
4. Check game lifecycle ordering
5. Confirm exact Stream ID spelling

Likely causes:

Create Stream never ran.
Wrong context.
ID mismatch.
Stream was removed.
Operation ran too early.

B. Sequential Results Changed After Refactor

1. Select Stream
2. Confirm Decision Mode = Sequential
3. Enable successful-operation recording in Runtime Controls
4. Reproduce old/new flow
5. Inspect Recent Decisions
6. Look for added/removed operations and Sequential Effect

Sequential results are call-order sensitive.

Adding one advancing operation earlier in the sequence can intentionally change later results.

C. Keyed Result Repeats

1. Confirm Stream is Keyed
2. Open Recent Decision
3. Compare Namespace
4. Compare Stable Subject ID
5. Compare Decision
6. Compare Occurrence

Same key + same occurrence intentionally repeats the same deterministic coordinate.

D. Keyed Result Unexpectedly Changes

Compare the actual retained sanitized Decision Key fields.

A changed:

Subject.
Decision.
Occurrence.

means a changed deterministic request.

Also confirm the deterministic contract versions are the expected ones.

E. Successful Operation Is Missing

Check:

Record Successful Operations

If it was false when the operation occurred, the Inspector cannot reconstruct it afterward.

Also check bounded history eviction.

F. Value Is Missing but Status Is Success

The operation may not participate in the approved generated-value capture contract.

Read:

Generated Value:
Not captured for this operation

as:

The operation succeeded, but its output type is intentionally unavailable to generic diagnostics.

G. Warning Appears Repeatedly

Use:

Warning guidance.
Related Events.
Raw status domain/code.
Stream configuration.
Caller ordering.
Input validation.

Do not immediately increase warning thresholds or retry counts.

H. Need to Preserve Evidence Before Teardown

Use:

Freeze View

then export the frozen snapshot after PIE ends.

68. Quick Decision Guide

Developer question	Inspector area
Does the Stream exist?	Streams
Fixed or Secure?	Streams / Selected Stream Details
Sequential or Keyed?	Streams
Which persistence policy?	Streams
Which deterministic contract version?	Selected Stream Details
What did this Stream recently do?	Recent Decisions
Did it advance Sequential RNG?	Sequential Effect
What supported result was returned?	Value / Decision Details
Which Keyed identity was used?	Decision Details
Why was an operation rejected?	Status + Events
Why do failures keep happening?	Warnings
Need stable evidence while game continues?	Freeze View
Need focused bug report?	Export Current View
Need everything copied from this context?	Export Full Snapshot
Need Unreal text logs?	Open Project Logs

69. Recommended Developer Workflow

For an ordinary Runtime investigation:

1. Start PIE
2. Open Probability Director Runtime Inspector
3. Select the correct Runtime Context
4. Find/select the Stream
5. Verify Seed Source / Decision Mode / Persistence Policy
6. In Runtime Controls, enable Record Successful Operations if successful calls must be observed
7. Reproduce the behavior
8. Review Recent Decisions
9. Review Events
10. Review Warnings
11. Open Decision Details when Keyed identity matters
12. Freeze View if you need to preserve the moment
13. Export if the issue must be shared

70. What Not to Do

Do not use the Inspector to:

Drive gameplay.
Reset RNG.
Guess a numeric Stream position.
Reconstruct Secure state.
Treat diagnostics as a save file.
Treat Recent Decisions as an unlimited replay log.
Treat warning count as a gameplay statistic.
Infer that every successful operation advanced Sequential state.
Infer that every missing Generated Value means failure.
Merge different PIE GameInstance contexts mentally into one global Stream registry.

71. Quick Reference

Streams
    = what exists and how it is configured

Selected Stream Details
    = deterministic contract identity

Recent Decisions
    = retained decision-oriented events for selected Stream

Events
    = broader retained diagnostic history

Warnings
    = repeated/suspicious conditions

Sequential Effect
    = Advanced / Did Not Advance / Not Applicable

Record Successful Operations
    = future successful-operation capture only

Freeze View
    = freeze Inspector presentation, not gameplay

Clear Diagnostics
    = clear diagnostic history only

Export Current View
    = current filtered/sorted presentation

Export Full Snapshot
    = complete copied selected-context snapshot

72. One-Sentence Summary

Use the Probability Director Runtime Inspector to understand what Probability Director is doing in a specific GameInstance without changing the Streams or exposing the RNG state that produced the results.

API Overview — obtaining the subsystem, Stream lifecycle, Sequential vs. Keyed, error handling.
Diagnostics and Warnings — retention rules, generated-value contract, warning meanings, security boundaries.
Dice — Dice Runtime semantics.
Lab-Dice — Dice Lab workflow and isolated Lab samples.
Probability — exact probability and Bernoulli/Binomial semantics.
Lab-Probability — Probability Director Lab isolated sampling.
Distributions — distribution Runtime/evaluation concepts.
Lab-Distribution — Distribution Lab isolated sampling.
Monte Carlo and RNG Health — isolated statistical simulation versus actual gameplay Streams.