Language models are least reliable about exactly one thing in engine work: what is true in your version. Training data averages across years of releases, so a feature that was Experimental for three versions, shipped as Beta, and is now Production Ready has all three states represented in what the model learned, with no reliable way to tell which one applies to you. The answer arrives confident and unlabeled either way.
This produces two failures that look nothing alike:
- Building on sand. A feature adopted as though stable turns out to be Experimental in your version — its API changes under you at the next upgrade, and its edge cases are documented nowhere because it was never meant to be relied on yet.
- Refusing free capability. A feature avoided as "experimental" that has actually been production-ready for several versions, so the project hand-rolls a worse version of it.
Both are avoidable in about five minutes, using evidence that is already on your disk.
Determine maturity before committing to a feature
- Never accept a maturity claim without a version. "Substepping is experimental" is not a statement about your project until it names an engine version. Treat unversioned claims — from a model, a tutorial, or a memory — as unverified.
- Check on this machine. Plugin descriptors, editor labels, deprecation macros, and
console variable help all carry maturity information in the installed engine. The
procedures are in
references/maturity-discovery.md. - Apply the guardrails for the level you found, not the level you hoped for. Experimental
is not forbidden — it is permitted with containment. See
references/decision-rules.md. - Record the finding with its evidence and date in the project context file. A maturity claim with no evidence is the thing this skill exists to prevent, and writing one down makes it authoritative for everyone after you.
- Re-check on upgrade. Maturity is the most upgrade-volatile fact in a project. See
references/drift-and-upgrade.md.
Load only what applies:
references/maturity-discovery.md— the four on-disk checks, in order of cost, and how to read each result.references/decision-rules.md— what each maturity level permits, and the containment an Experimental dependency requires.references/drift-and-upgrade.md— re-verification after an engine upgrade and what silently changes.
Required answer format
When this skill fires, return:
- Feature and version — the exact engine version checked against.
- Maturity finding — Production Ready / Beta / Experimental / deprecated / not present, and which check produced it.
- Evidence — the file, label, macro, or command output, quoted.
- Guardrails required — per
references/decision-rules.md, for the level found. - Decision — adopt, adopt with containment, or avoid, with the reason.
- Unverified — anything where the checks disagreed or returned nothing, marked explicitly rather than resolved by assumption.
Hard rules
- Never state a maturity level without naming the engine version it applies to. An unversioned claim is a guess even when it is right.
- Never infer maturity from a tutorial, a forum post, or a model's confidence. Those describe some version, and rarely say which.
- An Experimental dependency requires containment before the first line of code that uses it — an isolation boundary and a fallback plan, not an intention to add them later.
- Absence of an Experimental label is not evidence of stability. Check positively rather than concluding from what you did not see.
- A deprecation warning is a deadline, not a style note. Record which version removes it.
- Record the finding with its date. An undated maturity claim becomes wrong silently at the next upgrade, and nobody will know when it was last true.
Verification
The evidence test. For every maturity claim in the project, a named artifact must exist: a descriptor field, an editor label, a compiler warning, or command output. A claim nobody can produce evidence for is unverified — mark it so rather than defending it.
The upgrade re-check. After any engine version change, re-run the discovery procedure for every feature in the table and diff the results. Features move in both directions, and the ones that got more stable are worth finding too — they may retire code you wrote to work around them.
The containment test. For each Experimental dependency, confirm the isolation boundary is real: the number of files that reference it directly should be small and enumerable. If it is neither, the containment exists only in the design document.
Scope
This skill establishes what state a feature is in and what that implies. It does not decide
whether a feature is a good fit for your design, does not cover phase-driven exclusions
(ue5-phase-bans — a different decision with a different lift condition), and does not track
third-party plugin quality, which has no engine-published maturity label at all.
It deliberately contains no list of which features are Experimental in which version. Such a list is wrong within one release and cannot be verified from inside this repository. The procedures here answer the question for whatever version you are actually running, which is the only version that matters.