Core Concepts

This page explains the terminology and the data flow. Later pages assume these terms.

The two phases

The SDK operates in two phases.

Design time (editor only). Using your API key, the editor window talks to IMPACT to list programs and competencies, register apps, link a scene’s app to a program, create competencies, and download a per-app manifest. The API key is used only here and never ships.

Runtime (in the built app). Your gameplay code fires decision points; the tracker buffers them to disk and sends them to IMPACT in batches, retrying on failure.

Data flow at runtime

Your gameplay code
        │  Arm() / Fire()
        ▼
AruvrTrackImpact ──► AruvrTracker (singleton)
                          │  builds statements, buffers to disk
                          ▼
                     on-disk queue  ──►  batched HTTPS POST  ──►  IMPACT track endpoint
                          ▲                    (every 15s / on pause / on completion)
                          │  retries on failure (server de-dupes by statement id)

A decision point fires. The tracker creates a statement and appends it to a queue that is also written to disk (Application.persistentDataPath/aruvr_queue.json).
A background loop flushes the queue to the endpoint in batches (up to 100 statements per request) every 15 seconds, on application pause, and on completion.
On success the batch is removed. On failure it stays queued and retries. Every statement has a unique id, so retried or overlapping batches never double-count.
IMPACT parses the statements, attributes them to competencies, and updates the dashboard.

Because the queue is on disk, a session survives network loss, the headset sleeping, and the app being killed — nothing is lost.

Glossary of terms

Term	Meaning
Organisation	Your IMPACT account; owns programs, competencies, apps, and learners.
API key	Organisation credential used only in the editor. Powerful; never shipped.
App	An external application/scenario registered in IMPACT, linked to a program.
Program	An IMPACT training program grouping competencies and content. A scene reports into one program.
Competency	A named skill (e.g. “Correct Extinguisher Selection”) with an operational threshold, optional ESCO link, and description.
Decision point	A tracked moment in a scene — an `AruvrTrackImpact` or `AruvrAssignScore` component with a stable GUID.
Polarity	What firing a decision point means: correct (positive), incorrect (negative), or audit-only (neutral).
Latency	Time between `Arm()` and `Fire()` for a decision.
Learner id	Identifier for the trainee in a session.
Runtime token	Per-app, write-only credential baked into the build; can only submit tracking.
Manifest	`StreamingAssets/aruvr_manifest.json` — per-app runtime config (token + endpoint).
Statement	A single tracked event sent to IMPACT (a “scored” or “experienced” verb).

Polarity in depth

Polarity is central. Firing a positive decision point records a correct decision; firing a negative one records a mistake; neutral is recorded but excluded from accuracy and the confidence matrix.

A common design pairs two trackers on one competency — one positive (the correct action) and one negative (the mistake) — and fires whichever matches what the trainee did. This gives IMPACT both signals for the same skill.

Latency: Arm and Fire

To measure how long a trainee took to decide, call Arm() when the decision first becomes available and Fire() when it is made. IMPACT records the time between them. If you never call Arm(), latency is recorded as 0.

Decision point GUIDs

Each decision point has a stable GUID, generated automatically. History is keyed on it, so do not change it after release — doing so would orphan the previous data for that decision point.