PLH / 05 / Anticheat Expert
AnticheatExpert.
A diagnostics-first system identity utility shaped by more than 1,020 hours spent reversing anti-cheat architecture, failure modes, and update drift.
ACE / Diagnostics-first hardware stateVerified direction
No mystery button. No fake certainty.
The final public feature list will be published only after compatibility, rollback, and repeatability are validated. The sections below describe the product contract currently being verified.
Development specification
The behavior required before release.
Items are labeled as product requirements, not released claims. Detection status will remain “not released” until the supported environment has passed the complete verification matrix.
Know before changing
The product must describe the exact machine, support state, and blockers before any mutation is available.
- System readiness summary
Planned single view for firmware mode, platform state, privileges, and required services.
verification requirement - Supported-environment gate
Planned fail-closed check prevents use on an unknown OS or unsupported platform build.
compatibility contract - Firmware-mode visibility
Planned reporting distinguishes UEFI, legacy, secure-boot, and virtualization context.
read only first - Component inventory
Planned scope map shows which hardware identity families are discoverable and supported.
explicit coverage - Blocking issue list
Planned preflight explains exactly what prevents a valid run and how to resolve it.
actionable errors - Detection status panel
Planned status separates unreleased, testing, supported, degraded, and blocked states.
no ambiguous “safe” label - Last verified build
Planned compatibility record identifies the exact OS and target versions used in validation.
dated evidence - Dry-run inspection
Planned read-only mode reports intended actions without changing system state.
preview path
Every surface named
Supported identity families must be exposed individually, with source, current state, requested state, and persistence clearly separated.
- Firmware identifiers
Planned dedicated scope for supported SMBIOS and firmware-backed identity fields.
scope requirement - Storage identity
Planned per-device reporting avoids treating every disk path as one generic serial.
device scoped - Network identity
Planned adapter-aware controls distinguish physical, virtual, disabled, and transient interfaces.
adapter scoped - Platform security state
Planned visibility for security processors and related platform identity context.
state reporting - Operating-system identifiers
Planned separate handling for OS-generated identity families and local caches.
layered scope - User-selectable profile
Planned profiles group supported identity choices without hiding the individual operations.
transparent preset - Original-state capture
Planned baseline snapshot records the relevant pre-change state before apply becomes available.
rollback prerequisite - Per-surface support label
Planned supported, unsupported, unavailable, and unchanged labels for every identity family.
granular status
Reversible is a feature
Apply, verify, restore, and recover must be distinct phases with durable evidence and no invisible partial success.
- Transactional apply
Planned phase-based execution stops at the first failed invariant.
all stages named - Pre-change snapshot
Planned snapshot captures rollback inputs before any supported state is touched.
mandatory baseline - Post-change verification
Planned readback proves the observable state matches the requested profile.
verify after write - One-click restore
Planned restore path returns every supported surface to the captured baseline.
complete rollback - Interrupted-run recovery
Planned startup audit detects an unfinished transaction and resumes recovery, not application.
crash aware - Partial-state rejection
Planned product state never reports success when only some requested surfaces changed.
fail closed - Reboot-boundary plan
Planned state describes what is immediate, what requires restart, and what is persistent.
time semantics - Safe uninstall
Planned removal checks restoration status before deleting product-owned state.
recovery preserved
Evidence, not error codes
Every failure should name the layer, observed condition, expected condition, and safe next action.
- Stage-by-stage console
Planned console keeps preflight, snapshot, apply, verify, and restore phases visible.
live lifecycle - Exact failure detail
Planned messages name the failing operation instead of collapsing to “diagnostic recorded.”
actionable output - Compatibility report
Planned export contains versions, supported scopes, blockers, and verification results.
support artifact - Redacted by default
Planned logs avoid copying raw personal identifiers when a structural diagnostic is enough.
privacy first - Transaction receipt
Planned receipt records stage outcomes, timestamps, and restoration state.
durable evidence - Baseline diff
Planned comparison shows which supported surfaces changed and which did not.
before / after - Support bundle preview
Planned preview shows exactly what a diagnostic package contains before export.
user controlled - Failure acknowledgement
Planned interactive failures remain visible until the user closes them.
no vanished errors
Version changes stay visible
Every version-sensitive contract must be centralized, validated, and reported when an update changes assumptions.
- Central compatibility manifest
Planned build contracts live in one updateable source instead of scattered constants.
single ownership - Multi-invariant validation
Planned support checks use several meaningful invariants rather than timestamps alone.
drift resistant - Unknown-build rejection
Planned behavior blocks mutation when a system update no longer matches the validated contract.
fail closed - Compatibility history
Planned changelog records when a platform build entered, left, or regained support.
dated status - Update preflight
Planned client validates release metadata and local compatibility before replacing itself.
safe update - Rollback release
Planned release channel retains a verified recovery path when a new build regresses.
version recovery - Remote status, local decision
Planned status can announce support changes while the local client independently verifies state.
no blind trust - Detection continuity
Planned public status will show the verified start date only after release evidence exists.
no invented “UD since” date
Small, calm, explicit
The product should reduce a complex system to a clear workflow without removing the information needed to trust it.
- Readiness-first home
Planned first screen answers whether the system is supported before showing actions.
clear entry point - One primary action
Planned interface presents a single next valid step based on current state.
contextual CTA - Advanced details on demand
Planned expert view reveals exact invariants and scopes without cluttering normal use.
progressive disclosure - Persistent recovery access
Planned restore remains available even when the current environment is no longer supported for apply.
recovery priority - State-aware language
Planned labels distinguish ready, applying, verifying, restored, degraded, blocked, and unsupported.
7 clear states - No payment surface
The product page remains informational while private access is evaluated manually.
no public checkout - Ten-user ceiling
Planned access remains intentionally capped to preserve hands-on support.
private cohort - Release only after proof
Final capabilities and detection continuity publish after the complete validation matrix passes.
evidence threshold
1,020+ research hours
Research time is not release proof.
It informs the architecture, but the product remains in verification until compatibility, rollback, recovery, and detection evidence all agree.
Development status
Nothing for sale yet.
The page will move from specification to supported product only after verification. There is no waitlist payment or public checkout.
