Plugin Governance and Release Confidence

When strong evidence shows that one exact managed plugin build or dependency creates an active critical security threat, ADK can issue a narrowly scoped signed revocation. One authorized security authority must issue it and a separate authorized reviewer must confirm it. Store operators, commercial staff, popularity, ordinary defects, and a single reviewer cannot trigger it.

A server that receives the valid decision must stop treating those exact bytes as an ADK-managed safe choice. An offline server cannot receive new warnings, however, so it continues using its last known state while clearly showing that its security information is stale. The administrator accepts that risk; ADK does not disable ordinary plugin functionality merely because the server stays offline. Licensing uses its own separately agreed grace periods.

A developer may keep a plugin private while allowing ADK to inspect and compile it for managed distribution. The source goes only through a clearly named review route with declared storage, human access, and deletion rules.

Game servers do not upload plugin code to ADK. A locally built plugin can still be used under local server policy, but it does not become an ADK-managed marketplace release merely because its developer says it passed a local check.

Plugins say which framework features they need, prefer, or can use optionally. ADK can figure out much of this from the functions and data the plugin uses. It then asks developers only about things that can't be guessed safely.

For example, an event may require inventory transfer, prefer precise lighting, and optionally use positional audio. If precise lighting is unavailable, the plugin can use a declared simpler presentation without gaining direct access to the game renderer.

A plugin must declare the data it collects, stores, displays, sends, retains, deletes, or shares. That declaration gives ADK, administrators, privacy tools, and web pages one reliable description of the plugin's data use.

If the declaration is missing or invalid, ADK may restrict the plugin, disable its saved data, prevent central sharing, limit its web pages, or keep it local to the server. The declaration is therefore an enforceable part of the plugin, not merely documentation.

Plugins must describe how they change gameplay, players, server settings, and other systems. This helps admins decide if a plugin is safe to use. It also shows what changes might happen on their server.

ADK is designed to track dependency pressure, compatibility, security findings, update health, and signs that an important plugin may no longer be maintained. Administrators and developers could see the evidence and likely consequences before a neglected dependency becomes a wipe-night surprise.

ADK can apply an objective inactivity rule without guessing from one neglected release: by default, a publisher becomes abandonment-eligible only after one year without verified activity anywhere on that developer account. An old plugin may still be marked outdated or at risk while its publisher remains active, but it is not called abandoned merely because it has not received an update.

The resulting continuity path follows the developer's predeclared rights and continuity terms. Ownership transfer, source release, adoption, and other interventions still require their normal authority and review; popularity never bypasses safety rules and the framework does not seize third-party code.

This service checks if a plugin is ready for release. It combines developer claims with independent test results. The system uses this to decide if a plugin can move to public channels. The decision is only advice. Admins control final safety rules.

This service examines the fixed files in a plugin package and reports possible security problems to developers, reviewers, and administrators. Its findings are evidence, not a final judgment.

It does not activate, reject, or release the plugin, and it cannot replace human review or the protections used while a plugin is running. Those decisions remain with their normal owners.

A developer can keep plugin source private while still allowing ADK to inspect it safely. They may separately permit human-reviewed general design lessons, specific forms of code reuse, publication under an open-source licence, or encrypted source custody. A developer may also record willingness for future model uses, but ADK cannot perform a model-processing class until the framework has actually implemented its safeguards.

These are separate choices. Letting ADK check a private plugin for security does not quietly grant permission to copy it, train a model on it, or publish it. For example, a developer may choose private review-only source that is deleted after compilation, while another may allow ADK to adapt part of their work into the framework under clearly stated attribution and distribution terms.

A developer may deliberately ask ADK to retain an encrypted copy of plugin source or place it in escrow. This is separate from ordinary security review and is off by default.

The planned service would record who may access the source, why, for how long, and what must happen before escrow can be handed over. A plugin becoming popular, abandoned, or inconvenient would never be enough to unlock it.

Under this design, escrowed plugin source could be handed over only through an exact signed decision made by the people or authorities named when the escrow was created. The decision would identify the trigger, recipient, allowed purpose, and limits.

For example, a developer may permit release to named maintainers only after a defined inactivity period and several independent approvals. Popularity or an automated abandonment warning cannot replace those conditions.

Letting ADK inspect plugin source does not allow that source to become AI training material. Temporary analysis, search indexes, evaluation sets, fine-tuning, and long-term model training are different uses and require separate rules.

Until ADK has implemented and verified those controls, model training and durable AI learning from private plugin source remain unavailable—even when a developer would be willing to allow them. Human reviewers may retain an approved general lesson only through a separate review that proves it does not preserve or reconstruct the source.

Plugins must describe what they measure, why they measure it, who or what it concerns, where it may go, and how long it may remain. ADK can disable an undeclared analytics path while leaving unrelated plugin gameplay working.

For example, a minigame may report one local round-duration total without receiving permission to upload each player’s movement history.

This tool helps developers put together triggers, queries, rules, and intents using pre-made visual pieces. It creates the same kind of plugin files that regular tools use and lets them test trigger paths in a safe sandbox. It works like a fast Lego builder but isn’t a full programming environment.