GS-CompInt-2026

1. Purpose

GS-CompInt-2026 is an open standard that lets any game studio independently verify whether competitive-intelligence recommendations actually worked, using a portable JSON export and a runnable statistical validator.

Competitive-intelligence platforms claim their recommendations work. Studios have no way to check.

GS-CompInt-2026 defines a portable JSON format for exporting the causal outcomes of competitive-intelligence recommendations, plus a runnable validator that re-derives statistical significance independently. A studio can export its data from any conforming platform, run the validator on its own machine, and confirm whether recommended actions actually moved the needle — with no trust in the vendor required.

This is the standardisation layer for open causal analysis in the gaming industry: outcomes are verifiable by anyone, not asserted by the platform.

2. Conformance & normative language

An export conforms to GS-CompInt-2026 when it is a single UTF-8 JSON object with schema_version equal to "GS-CompInt-2026", a valid exported_at ISO-8601 timestamp, and cohort-level-only outcome records.

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in IETF BCP 14 (RFC 2119 / RFC 8174) when, and only when, they appear in all-uppercase as shown here.

An export conforms to GS-CompInt-2026 when:

1. It is a single UTF-8 JSON object.
2. schema_version MUST equal the exact string "GS-CompInt-2026".
3. exported_at MUST be a valid ISO-8601 timestamp representing UTC epoch seconds of data generation.
4. Every element of outcomes (if present) MUST satisfy §5.
5. Outcome records MUST NOT contain per-player rows or personally identifiable information — only cohort-level aggregates.

A validator conforms when, given any export, it (a) rejects non-conforming inputs with exit code 1, and (b) reproduces the causal verdict in §6 for every outcome. The reference validator is scripts/validate-outcome.ts.

A producer conforms when every export it emits conforms. Producers MAY include additional fields; validators MUST ignore fields they do not recognise.

3. Semantic conventions

Five normative column identifiers — platform_provider, metric_latency_tier, concurrency_count, retention_delta, and vulnerability_score — MUST be used verbatim by all conforming producers to ensure cross-vendor interoperability.

Interoperability across vendors requires a shared, language-agnostic vocabulary for core game telemetry. The following column names and value formats are normative — a producer MUST use these exact identifiers and MUST NOT substitute synonyms or vendor-prefixed variants.

4. Top-level schema

A GS-CompInt-2026 document is a JSON object with two required fields (schema_version and exported_at) and five optional arrays: outcomes, telemetry, jira_events, sentiment_signals, and playbook_executions.

Producers MAY include additional fields; validators MUST ignore fields they do not recognise. Opaque arrays carry supporting evidence behind each outcome but are not required to reproduce the verdict.

5. Outcome record

Each outcome record requires four fields: action_type (the recommended action), pre_retention (7-day baseline %), measured_retention_delta (observed change in %), and cohort_size (≥ 2 players). No PII is permitted.

Each outcomes[i] is the minimal pre/post snapshot needed to reproduce a causal test:

Privacy: outcome records carry no PII and no per-player rows — only cohort-level aggregates. This is the unit at which causal claims are made and verified.

6. Validation algorithm (normative)

The normative significance test is a two-proportion z-test (binomial model). A verdict of positive requires p < 0.05 with a positive effect direction and cohort ≥ 30; p ≥ 0.05 yields inconclusive; p < 0.05 with a negative effect yields negative.

Retention is a proportion — the fraction of a cohort still active at day N. The correct significance test for the difference between two proportions is the two-proportion z-test (binomial model):

n          = cohort_size                       # per arm; require n ≥ 30, else inconclusive
p_control  = pre_retention / 100               # baseline proportion in [0,1]
p_treat    = (pre_retention + measured_retention_delta) / 100

se         = sqrt( p_control·(1−p_control)/n + p_treat·(1−p_treat)/n )   # unpooled
z          = (p_treat − p_control) / se        # 0 when se = 0
p_value    = 2 · (1 − Φ(|z|))                 # two-tailed; Φ = standard normal CDF

Φ is evaluated with the Abramowitz & Stegun (1964) §26.2.17 rational approximation (max error < 7.5e-8).

5.1 Why the z-test, not Welch's t-test

Earlier drafts validated retention with Welch's t-test applied to a cohort-scaled revenue proxy. That is incorrect for proportions and is replaced here:

• A proportion's variance is structural — p(1−p)/n — not a free parameter estimated from a sample. Modelling retention as a continuous variable misstates the uncertainty.
• In the proxy formulation, the standard deviation scaled with the cohort, so the t-statistic grew as t ∝ √(cohort) regardless of the true effect size. At large cohorts this manufactured causal confidence the data did not support.
• The two-proportion z-test uses the binomial variance directly, so the statistic reflects the evidence, not the sample size. A 0.5 pp lift on 100k players is genuinely significant; the same lift on 200 players is not.

Continuous outcomes (revenue per player, playtime, ARPDAU) are a different metric type and do use Welch's t-test for unequal variances; a producer signals metric type so the validator routes correctly.

Verdict table:

7. Reference validator

Run npx tsx scripts/validate-outcome.ts export.json to validate any GS-CompInt-2026 document locally — no Metriqal account required. Exit code 0 = all outcomes positive; 1 = schema violation; 2 = ≥1 outcome inconclusive or negative.

# human-readable
npx tsx scripts/validate-outcome.ts export.json

# machine-readable JSON
npx tsx scripts/validate-outcome.ts export.json --json

# pipe mode
cat export.json | npx tsx scripts/validate-outcome.ts

Exit codes:

• 0 — conforms and all outcomes resolved positive
• 1 — schema violation or malformed input
• 2 — conforms but ≥1 outcome inconclusive/negative

8. Security model

Exports are gated by HMAC-SHA256 portal-key auth with strict tenant isolation. Sensitive developer-velocity events are sanitised client-side into anonymised category tokens before leaving the studio's network. No PII may appear in any conforming export.

Your data is yours. Metriqal is the wiring. The standard is designed so a studio never has to surrender raw internal data to gain competitive-intelligence signals. The threat model below follows the guidance of IETF RFC 3552 (Security Considerations) — it documents the assets, the trust boundaries, and the controls explicitly so that an information-security reviewer can evaluate the standard without a sales call.

8.1 Export API authorisation

The Metriqal export endpoint (/api/export) enforces HMAC-SHA256 portal-key authentication. Each request MUST include a Bearer token signed with the tenant's secret; the server validates the token and asserts strict tenant isolation before returning any data. Cross-tenant reads return HTTP 403 Forbidden regardless of token validity. Unauthenticated requests return HTTP 401 Unauthorized.

This architecture is documented publicly so that information-security evaluators at prospective studios can verify the threat model without a sales call. The security controls are not assertions — they are auditable code.

8.2 Selective disclosure for developer-velocity events

Studios are not required to transmit raw internal data. The GS-CompInt-2026 standard natively supports a selective-disclosure pattern for sensitive events such as Git commits, Jira sprint closures, and Stripe transaction streams:

• Raw events MUST pass through a client-side sanitisation filter before export.
• The filter parses intent locally and emits a standardised, anonymised category token. Proprietary code details MUST NOT leave the studio's network.
• Producers SHOULD implement the filter as open-source so studios can inspect it before deployment.

Example — a commit message "Fixed critical matchmaking crash in build 412" is parsed locally and transmitted as:

{
  "event_type": "developer_velocity",
  "modification_scope": "stability_patch",
  "impact_area": "multiplayer_matchmaking",
  "timestamp": 1781076844
}

The raw message never leaves the studio's firewall. The category token is sufficient for the platform to compute developer-velocity signals without accessing proprietary code or project details.

8.3 PII boundary

Outcome records MUST contain only cohort-level aggregates. No per-player rows, device identifiers, account IDs, or IP addresses MAY appear in a conforming export. This constraint is enforced by the reference validator — any outcome record containing a player_id or similar field MUST be rejected with exit code 1.

9. Discovery endpoint

Third-party tools discover the current schema at https://metriqal.se/.well-known/gs-compint-2026.json — a machine-readable JSON document containing the full schema description, validator invocation, and exit code definitions.

The discovery document is machine-readable and includes the full schema description, validator invocation, and exit code definitions. Any third-party tool can resolve this endpoint to detect conformance requirements without consulting this specification.

10. Versioning

The version string is the contract: breaking changes increment the year (e.g. GS-CompInt-2027); non-breaking additions do not. The -draft suffix MUST NOT appear in a published export.

The version string is the contract. Breaking changes increment the year or suffix (e.g. GS-CompInt-2027). The -draft suffix is reserved for pre-publication and MUST NOT appear in a published export.

Non-breaking additions (new opaque array fields, new optional outcome fields) do not increment the version.

11. Non-goals

GS-CompInt-2026 does not standardise proprietary predictive models, real-time streaming protocols, studio-internal metrics, or data-collection rights. It governs only how competitive-intelligence outcomes are formatted and exchanged.

The scope of GS-CompInt-2026 is intentionally narrow. The following are explicitly outside the specification:

• Proprietary predictive models. The specification governs how data is formatted and exchanged, not the algorithms used to generate competitor sales estimates, revenue projections, or machine-learning inferences. Each platform vendor retains full discretion over their modelling methodology.
• Real-time streaming protocols. GS-CompInt-2026 defines a batch export format (JSON). Streaming transports (WebSocket, Kafka, NATS) are out of scope and may be addressed in a future extension.
• Studio-internal metrics. First-party data such as raw playtime logs, crash telemetry, and IAP receipts are not standardised here. The standard governs competitive-intelligence signals derived from public and multi-platform sources.
• Rights and licensing of underlying data. Each platform_provider's terms of service govern the permissibility of collection. GS-CompInt-2026 does not grant or imply any data-collection rights.

12. Conformance program

Any producer or validator may self-certify as GS-CompInt Certified Conformant by running the reference validator and submitting the JSON output via the discovery endpoint — free, self-attested, and Metriqal-approval-free.

Any producer or validator implementation may self-certify as GS-CompInt Certified Conformant by:

1. Running the reference validator against a conforming export: npx tsx scripts/validate-outcome.ts export.json --json
2. Confirming exit code 0 and a validator report with zero schema violations.
3. Submitting the validator output (JSON) and a link to the producer implementation via the discovery endpoint.

Certified implementations MAY display the GS-CompInt Certified Conformant badge in their repository README. Certification is self-attested, free, and does not require Metriqal approval — the validator is the arbiter, not the platform.

13. Example

A minimal conforming document has two fields (schema_version and exported_at) plus an outcomes array. The reference validator produces a verdict per outcome: a 12,000-player cohort with +6.5pp retention delta resolves as positive; a 5-player cohort resolves as inconclusive.

{
  "schema_version": "GS-CompInt-2026",
  "exported_at": "2026-06-13T12:00:00.000Z",
  "outcomes": [
    {
      "action_type": "aggressive_uacq",
      "pre_retention": 38.0,
      "measured_retention_delta": 6.5,
      "cohort_size": 12000
    },
    {
      "action_type": "review_bomb_containment",
      "pre_retention": 41.2,
      "measured_retention_delta": 0.3,
      "cohort_size": 5
    }
  ]
}

Running the reference validator reports the first action as positive (large cohort, significant effect) and the second as inconclusive (cohort too small to reject the null at α=0.05). Any third party reproduces the same verdicts with no dependency on Metriqal's infrastructure.