Default availability and backend readiness

Reviewed 2026-10-25 against the public source at 4d05e738e88022a458e161a0abcd19b301d01889, with SDK 2.4.0, plugin ABI 1.1, and game pack 0.8.0 as the compatibility baseline. This review identifies the work needed for comprehensive defaults. It records no new Windows, launcher, or game run and changes no capability, source flag, release approval, or provenance decision.

The published sdk-v2.4.0-rc.1 source is 48d7055ef49e1b073ec59e4ce8ded7a6006329eb. That archive snapshot, current source changes, and final signed release approval are separate. This document is a source review for the development branch, not a statement that published RC1 bytes include its changes.

Implemented defaults in this development change

All fourteen read-only discovery/workflow tools are offered by default; the six-tool profile is selected with --minimal-tools. Build/check execution is offered once an operator configures project roots, retaining fixed commands and confinement. Platform::pluginsEnabled now defaults true, but discovery still requires an explicit nonempty pluginRoot; false retains the built-ins-only path. Tests cover configured-root loading, explicit disable and empty-root behavior.

This review does not enable unfinished native methods or infer consent/quiescence. Generic gameServices remains explicit because duplicate service names currently stop composition partway while app startup continues; globally enabling it would risk incomplete service publication. A complete game host must first establish service ownership, adapters and admission. DataCore requires an applying adapter; ImGui requires renderer integration; runtime inspection requires its independent consent/offline/audit prerequisites described below.

The position-only relocation source extension was reviewed on 2026-10-26 against base e75219bcdf856e3798ab9e99e26315041d14b6e1; its separate OFF/synthetic row below adds no native activation.

Reading availability correctly

The status registry contains 38 named capabilities whose recorded default is OFF: 25 have synthetic_only evidence and 13 have off_pending_probe evidence. All 38 appear once in the inventories below. A registry entry records the reviewed availability/evidence baseline; actual host capability state is also computed from signatures, configured providers, admission, cleanup and fault state. The quantum path below already attempts production setup automatically under those conditions, despite its conservative OFF registry entry. Do not infer that changing a registry field changes runtime implementation.

The roadmap separates contract, mock, static evidence, grounded native backend, game evidence and default-on behavior. Its post-2.4.0 work explicitly includes narrowed native rays, entity lookup, live GameRules values and audio. Comprehensive discovery should expose those contracts and their readiness honestly. Comprehensive behavior requires completing their adapters and acceptance work, rather than treating an unavailable response as a hidden switch.

The sources and tests linked here are public project material. Test links identify relevant verification work; they do not assert a fresh pass in this review. No proprietary executable, dump, address list, private analysis or player data is required to read this inventory.

Native paths with explicit configuration or proof holds

These seven capabilities have identifiable production native paths. Configuration can select some of them today, but the documented missing acceptance and lifetime requirements remain. None can be called game-verified from this review.

Capability	Current source and selection	Runtime prerequisites and owed evidence	Candidate action
`game.datacore_live`	host options, Prepare, native adapter. `Options::nativeDataCoreReads` defaults false; `preEngineQuiesced` is a separate assertion. Native writes always return unavailable.	Windows game-service build; positive shell admission; `platform.dataCore`, `platform.gameServices`, required DataCore hook and valid data root; engine quiesced before Prepare; resolved lifecycle/owner rows; unique hook ownership; lifecycle exclusion and fresh admission on reads. The shell must actually provide quiescence; a late flag cannot establish it. See lifecycle guide and engine tests.	Integrate and prove the shell lifecycle boundary, then evaluate native reads on a named target build. Do not enable the read default by also asserting quiescence automatically, and do not extend that decision to writes.
`game.actor_stats.write`	actor stat service, `SetActorStatWritesEnabled(bool)` or the existing `SCO_ACTOR_STATS_WRITE=1` test setting. Contract guide.	Read prerequisites and write rows must resolve; every write requires fresh offline admission, own-player identity, a supported 1..9 stat, finite/bounded step and the game’s authority/local-change rule. New read IDs do not expand the write allowlist. Units, effects and real readback remain to be observed in game. Write boundary fixture.	A host setting can expose controlled testing now. Default enablement needs named-build write/readback and consequence evidence; retain admission, identity, bounds and authority guards.
`game.inventory.read`	inventory host, `g_enabled{false}`, `SetInventoryReadEnabled(bool)` and `SCO_INVENTORY_READ=1`; native item-port adapter.	Resolved inventory rows, valid local-player reads, checked native receiver/vtable identities and bounded tree walk. The snapshot format and actual native object behavior are synthetic/static evidence only; inventory guide says the live confirmation is owed. Engine fixture.	Test actual player item-port snapshots, truncation and missing/changed objects before making the host setting default-on. Keep bounds and receiver checks.
`game.inventory.layout`	layout service; no production producer is installed.	The versioned copied contract, lifecycle and refusal paths have synthetic host tests; logical identities and roles are not grounded in the native adapter.	Establish a producer with stable scoped keys, complete observations and lifecycle guards, then validate the target host before enabling the capability.
`game.cvars.read`	production configuration uses `SCO_CVARS_NATIVE=1`; otherwise it installs an empty port. Native CVar adapter.	Resolved console/lookup/reference-integer identities, exact receivers/methods, fresh admission and a fault-free installed service. Only the reviewed reference-integer surface is supported. CVar guide still owes owner-run Windows and real-value observations; production fixture.	Validate the four real values and native object identity/lifetime on the named host, then consider automatic read configuration. Do not let the read decision turn on writes.
`game.loadout.async`	production async adapter, `ProductionLoadoutBackend()`, selected by `SCO_LOADOUT_ASYNC=1`; service.	Required attachment/port/spawn/class rows, fresh G1 admission and stable session, live local player/parent identity, bounded port walks, async spawn/attach/readback, timeout/cancel/cleanup and fault latch. Loadout guide separates synthetic native-object evidence from actual slot/game behavior; native fixture.	Run named-build equipment/readback, parent-change, cancellation and release cases before changing the native adapter’s default selection. Preserve session, cleanup and uncertain-attachment rules.
`game.quantum.control`	service startup already calls `ConfigureDefaultProductionQuantum()` and `StartProductionQuantum()`; native setup. There is no extra environment opt-in at that call site.	Game thread, fresh positive admission at setup, all required hook/CVar/drive rows, unique hook ownership and owner cleanup. Runtime observations must remain offline/EAC-clear and have a drive. Bounded owned changes restore prior state on release; faults latch restart. Quantum guide records the scope and still lacks Windows/game acceptance.	Reconcile observed runtime readiness with conservative registry metadata only after evidence. No additional default switch needs flipping here. A plugin’s `enable`/`hold` request remains intentional feature use, not automatic gameplay activation.
`game.mining`	native mining adapter has `constexpr bool kNativeVerified = false`; service exposes requested/active/refusal state.	Verified native row/ABI, fresh G1 host admission on the native worker, owner cleanup, exact argument/flag/LOD guards, SEH fault containment and process-retained pass-through detour lifetime. Mining guide explicitly says native Windows/game verification is missing; synthetic fixture. `request` can accept intent while unavailable; that is not activation.	Complete the Windows native/worker/cleanup and gameplay acceptance before changing the verification constant. Retain per-owner intent and separate requested versus active status.

Native implementations held for specific game probes

These twelve additional capabilities have fixed proof holds rather than a general user configuration flag. Their row matches or synthetic provider tests do not answer the specific semantic question listed here. The candidate action for each is to perform and record that named-build probe, review the result, and only then update its proof attestation and registry/docs together. Do not manufacture proof by setting probed or a confirmation constant true.

Capability	Native path and hold	Required observation before default activation
`game.actors.state`	actors resolves probe rows but forces the capability false; event contract notes explain the predicates.	Establish which native predicate means dead and which means incapacitated for the reported actor, including transitions. Current probe availability is not a public state guarantee.
`game.world.free_camera_flag`	world provider sets `FreeCamFlagProvider::probed = false`; free-camera policy, guide.	Confirm that the read byte tracks free-camera enable/disable on the intended game build; this read-only flag does not establish a free-camera control backend.
`game.entities.query_radius`	entity provider; entity host definitions set `kQueryRadiusConfirmed = false` (B3).	Confirm native entity-walk threading, flags, completion and returned radius contents. Retain bounded/copy semantics.
`game.entities.watch`	entity provider; `kWatchConfirmed = false` in host definitions (B9).	Confirm stream-hook thread/lifetime, vector layout and event ownership/unsubscription on the actual host.
`game.events.vehicle_seat`	events holds the capability false even when its diagnostic hook rows are ready.	Confirm which actor owns a seat transition and that the payload identifies a vehicle seat, then establish correct callback data/lifetime.
`game.hangar.lift`	native provider sets `HangarProvider::probed = false`; policy, guide.	Confirm landing-area/lift lookup and open/close requests with actual valid IDs, row/receiver checks and observed effects.
`game.hangar.atc_cancel`	Same native provider and shared `probed` hold; policy.	Confirm ATC component/request ownership and cancellation result on the named host. This does not add ASOP store/retrieve operations.
`game.reputation.checks`	native provider sets `ReputationProvider::probed = false`; policy, guide.	Confirm the copied reputation check observations and native service/site identities from a real plugin.
`game.asop.claim_timeout`	native provider sets `AsopProvider::probed = false`; policy, guide.	Confirm configuration receiver, timeout value and seconds semantics, including unavailable/null cases.
`game.asop.shard_persisted`	Same native provider, separate rows/callback, shared `probed` hold.	Confirm the copied persisted flag and its meaning on the intended offline host; do not infer online/session authority from a flag.
`game.contracts.stream_radius`	native provider sets `ContractsProvider::probed = false`; policy, guide.	Confirm native mission-settings receiver and actual stream radius/unit semantics through the public consumer call.
`game.pak.all_files`	persistent CryPak hooks reject `Scope::AllFiles` unless `Options::allFilesProbed`; host options, design.	Confirm persistent hook re-entry/lifetime, replacement mounts and frame-time behavior. This is broader than the existing DataCore-only path; a scope change needs its own acceptance and rollback evidence.

Public contracts with absent or unready production backends

These nineteen capabilities require implementation or lifetime/registration grounding in addition to a future default decision. There is no truthful configuration-only completion. Public contracts and mocks can still support SDK-based consumer development while the native call answers unavailable.

Capability	Current provider/source evidence	Work required and roadmap boundary
`game.audio.triggers`	audio service starts with an empty AudioBackend in production composition; synthetic owner/token/cleanup behavior exists.	Ground a host-owned isolated native effect provider with resolve/play/stop and lifetime/cleanup proof, then audible/native acceptance. See audio guide, tests, roadmap Milestone 3.
`game.audio.play_once`	Same service; capability explicitly remains false because current game-object registration witness is ungrounded. No native production backend ships.	Complete the narrowed fire-and-forget backend, prove current registration/lifetime at submission and fault/restart behavior. This is one of the explicit four post-2.4.0 native deferrals; a trigger token alone is insufficient.
`game.inventory.contents.read`	container provider publishes with empty production callbacks unless a host supplies a snapshot backend; guide.	Ground a bounded copied-item native snapshot adapter with object lifetime, truncation and cleanup evidence; retain synthetic contract fixtures. Item-port inventory does not automatically supply stored contents.
`game.world.raycast_filtered`	world composition publishes control policy but forces the capability false: no verified native adapter.	Ground the narrowed single-hit filtered native path, grid/hit object lifetime and fault containment, then actual hit/filter observations. This is one of the four post-2.4.0 deferrals. See world-control design and policy tests.
`game.world.raycast_filtered_many`	Same composition and bounded multi-hit policy; no native grid/hit adapter.	Implement/verify actual copied multi-hit output, filter behavior, bounds/order/truncation and lifetime; single-hit backend evidence cannot be expanded silently to multi-hit behavior.
`game.world.free_camera`	Same world-control policy; no verified offline engine camera adapter.	Ground acquire/step/release and restoration against live object ownership, session/lifecycle and fault paths. A readable free-camera flag is insufficient.
`game.entities.lookup`	entity provider declares no verified registry/name/component adapter; portable copied lookup policy and fixtures exist.	Complete the narrowed exact-class-name lookup backend and copied typed-presence/lifetime boundary. It is one of the four post-2.4.0 deferrals. Broader lookup calls need their own proof.
`game.events.loadout_respawn_completed`	loadout service can accept a verified host producer but production has no resolved native respawn-completed occurrence/hook; guide names F-INTAKE-004/T-3.	Locate and ground the actual occurrence, thread/payload/re-arm/lifetime, then prove one correctly owned event per occurrence. Async equipment completion is a different event.
`game.loadout.apply`	production composition calls `StartLoadout(nullptr, ProductionLoadoutBackend())`; service has no verified synchronous equip backend.	Ground typed synchronous equipment methods and per-slot mapping/readback/cleanup, or retain the documented async route as a distinct contract. A working async adapter cannot certify synchronous apply.
`game.loadout.weapons`	loadout service additionally requires verified `engine.weapons`; production synchronous backend is empty.	Ground and test weapon/multitool slot semantics independently, including failed/partial equips and no duplication/corruption. Existing wearable vocabulary is not weapons proof.
`game.relocation.position`	Explicit 1.1 contract, provider/socket, actual provider fixture. The existing native FullPose adapter supplies no position callbacks; capability remains OFF with synthetic evidence.	Ground a position-only local-player transport, current copied target epoch, independent target-instance token changing on replacement/reparent/reset, and fresh target-frame readback. Preserve live-owner/session/system/admission/cancel/fault guards. The NPC local-frame setter and full-pose transport do not prove cross-zone position semantics; no guessed loaded-zone registry or probe attestation.
`game.gamerules.read`	GameRules service starts with empty GameRulesBackend. Static `list_params` metadata is separately available.	Complete the narrowed live value-change read backend with current parameter object lifetime and typed copied values. This is one of the four post-2.4.0 deferrals. Metadata definitions never imply live values.
`game.cvars.write`	native write mechanics exist, but production configuration calls `native.Install(resolved, false)` even with `SCO_CVARS_NATIVE=1`.	Establish native registration/backing lifetime across setter callbacks and retained leases, plus identity-safe restore and Stop/cleanup admission. The environment switch cannot supply that evidence. See host Stop fixture and CVar guide.
`game.economy.read`	offline backend seam has no production balance backend; production composition calls `offline::Start()` with empty callbacks.	Supply an independently validated offline balance reader with fresh session/admission and fault containment. See design, synthetic tests.
`game.economy.apply`	Same provider; capability requires admission, balance and atomic apply callbacks.	Ground exact compare/update behavior and uncertain-failure receipt/replay/session semantics; no network/account authority is implied. Requires more than a balance reader.
`game.missions.read`	Same empty production offline backend; capability requires admission, offer and status callbacks.	Ground native offer/status reads with copied bounded identifiers and session consistency.
`game.missions.accept`	Same seam; capability requires admission, offer and accept callbacks.	Ground native acceptance and owner/session lifetime, failure/idempotency and actual accepted mission observations. Read-only offers do not certify acceptance.
`game.missions.progress`	Same seam; capability requires admission, status, objective and advance callbacks.	Ground native objective/phase progression and abandon/cleanup behavior under bounded session-lifetime ownership. Retain synthetic ledger/refusal cases.
`game.missions.scripts`	Same seam; capability requires admission and ingest callbacks. No production script adapter is supplied. Hosts after SDK 2.4 RC1 expose owned `missions/<id>.scom` declarations through `sco.content`; RC1 lacks that discovery rule.	Ground the actual offline script consumer and bounded content/schema handling; copied declaration reachability does not enable native ingestion or execution.

Host, build, MCP and network defaults

These controls are separate from the 38 game capability entries. Build inclusion, tool discovery, executable access, service publication, privacy disclosure and gameplay activation need distinct decisions.

Control	Current source/default	Comprehensive-default action and required boundary
Star Citizen source build	CMake, `SCO_GAME_SC=ON` already. Core-source archives intentionally omit the game pack and must configure OFF.	Keep game-pack inclusion for the complete host-source target and preserve the neutral core-source profile. An absent source component cannot be made available with a build switch.
Retained widgets / ImGui renderer	`sco_widgets` is always built; `SCO_WIDGETS_IMGUI=OFF` controls the host-specific adapter in CMake.	Consider enabling the adapter for a host profile that provides matching ImGui headers, implementation, linkage and renderer acceptance. A generic SDK/core build cannot infer the product renderer; the retained public API is already available.
Runtime native peer build	`SCO_BUILD_RUNTIME_MCP=OFF` in CMake.	Building/packaging the native peer by default is separable from connecting it. A decision to include it still requires platform build/packaging tests and provenance; it must not fabricate adapter hash, credentials or host admission.
Generic plugin loading	app Platform, `pluginsEnabled=true` in this development change; discovery still requires a nonempty configured root. Built-ins load regardless. Products may explicitly disable external discovery.	The default host path enables plugin discovery for the configured root while retaining explicit owner disable markers, manifest/dependency checks and the product’s chosen root. Do not silently load code from an inferred working directory.
DataCore service publication	`Platform::dataCore=false`; requires the host’s applying CryPak/DataCore adapter and data root.	Enable for the complete admitted host composition when that lifecycle is configured; keep an explicitly neutral/minimal host valid. Native live read/write readiness remains separate.
Game-service publication	`Platform::gameServices=false`; app and game host coordinate publication.	Enable in a complete game-host profile only after resolving ownership of names already provided by the product and preserving prepare/start/stop/admission order. Published tables still return unavailable where their native backends are absent.
Reload copies	`Platform::loadFromCopies=false`; developer mode can map copied modules.	A developer host can choose copies by default if its filesystem/update/cleanup behavior is covered. This does not authorize hot replacement of mapped native modules or fault recovery.
Public MCP discovery	SDK discovery server originally gated the six extra static tools behind `--extended-tools`; workflows were initially a separate flag.	Default comprehensive public discovery and workflow retrieval are configuration/discovery changes. Keep explicit reduced-profile controls for old client allowlists, and preserve matching source/SDK metadata and bounded retrieval. No game attachment is needed.
Local MCP build/check	Existing development tools use `--enable-dev-tools` plus one or more `--project-root`, fixed programs, timeout/output bounds and process-tree termination.	Automatically offer the complete build/check surface when a developer has configured the necessary project roots/programs. Retain containment, fixed-command arguments and unavailable reasons when inputs/toolchains are missing. Do not infer unrestricted filesystem execution from a catalogue connection.
Runtime inspection connection	runtime launcher, host policy: enable setting, model-disclosure consent, exact six-tool allowlist, pinned local adapter/credential, positive offline admission and protected audit collector. Free-form disclosure is independent.	Make setup and readiness visible, but preserve the evidence/configuration requirements. A compiled peer or discoverable API cannot attest consent, a live protected audit collector, adapter identity or fresh offline status. Runtime acceptance records missing Windows/manual evidence.
Private co-presence	ControlPolicyV1 is already enabled; default bind/peers are loopback. Host/join requires fresh local consent and session admission.	Keep complete public SDK support for the roadmap’s private LAN/VPN co-presence. Do not expand network addresses, open sockets, store a passphrase or claim user consent as an effect of tool discovery.

SDK-first work and acceptance handoff

Each resulting implementation task should name a roadmap milestone and the public contract/member/version it serves. Milestone 2 requires product features to be public-SDK consumers and studio mocks to implement the same tables. Milestone 3 requires native grounding and game evidence before its default-on stage. An agent should:

Pin the SDK archive/source, host/product revision, language and target toolchain independently.
Build the smallest author-owned plugin using public headers and matching contracts/catalogue; add a synthetic/mock case for each changed availability, size/version, lifetime and cleanup decision.
Record whether the work changes discovery, build inclusion, service publication, native readiness or actual gameplay behavior. Test each changed layer rather than using success in an earlier layer as proof of a later one.
For a native readiness change, retain the specific prerequisite from the table, the fail-closed/refusal cases, named Windows target evidence and separately recorded owner-run game observation. Missing game access leaves that gate open while supported SDK/mock work proceeds.
Update registry/docs/receipts from observed results and keep published RC bytes, development source and final release approval distinct. A human provenance/release decision remains a separate step.

This review’s suggested next actions are comprehensive public discovery and workflow routing first; complete profile configuration and reproducible SDK-only consumer checks second; then prioritized native adapter/probe tasks with their existing safeguards and roadmap acceptance criteria. No capability listed above becomes implemented or game-verified merely because its interface is visible by default.