STRUCTÜR
Adaptive Governance Protocol (AGP) Standard
Version 2.0
Published by Structür
structur.services/agp
PREAMBLE
Second Life is a shared environment.
Every scripted object operating within that environment exists alongside other residents, communities, venues, parcels, and systems. The Structür Adaptive Governance Protocol (AGP) Standard exists to define what it means to build responsibly within those shared spaces — to create systems that behave predictably, operate thoughtfully, respect their surroundings, and remain appropriate to their intended purpose.
AGP is not intended to restrict creativity or discourage experimentation.
Expressive, atmospheric, playful, chaotic, immersive, and technically ambitious creations all have a place within shared virtual spaces. AGP exists to encourage thoughtful operational behavior alongside that creativity.
Meeting this standard should not be difficult for creators who already build with care. AGP is a codification of responsible practice, not an imposition of unnecessary constraint.
CATEGORY 1 — ACCESS CONTROL
1.1
Owner-level commands and configuration controls must respond exclusively to the object owner or verified same-group members unless intentionally documented otherwise.
1.2
Public interaction — where intentionally permitted — should be explicitly designed and documented. Default behavior should favor operational restraint rather than unrestricted access.
1.3
Objects accepting chat commands should use non-default channels for privileged functions. Channel 0 open-chat commands are discouraged for privileged operations.
1.4
Listen handlers must verify the identity of the sender before acting on privileged commands regardless of channel used.
CATEGORY 2 — SOUND AND MEDIA
2.1
Objects that play sounds autonomously should implement reasonable cooldown periods between activations appropriate to their intended purpose.
2.2
Sound volume should remain proportionate to the intended use of the product and appropriate to shared environments.
2.3
Objects should avoid continuous or excessive sound behavior that unnecessarily disrupts normal activity within shared spaces.
2.4
Media and sound functions should not be used to intentionally harass, target, or repeatedly disrupt specific avatars.
2.5
Looping sounds should provide an owner-accessible mechanism to stop playback.
CATEGORY 3 — OBJECT REZZING
3.1
Objects that rez child objects must verify parcel permissions before attempting to rez. Permission failures should be handled gracefully without excessive error output.
3.2
Rezzed child objects must carry either the TEMP_ON_REZ flag, an explicit cleanup timer, or another reliable cleanup mechanism appropriate to the object’s purpose.
3.3
Child objects should not themselves rez additional uncontrolled objects without clear operational justification.
3.4
Rezzed physical objects should use mass, velocity, and behavior appropriate to their intended purpose and surrounding environment.
3.5
The number of simultaneously rezzed objects should remain proportionate to the intended operational purpose of the system.
CATEGORY 4 — PHYSICS AND MOVEMENT
4.1
Movement functions such as llPushObject should not be used in ways intended to non-consensually disrupt or harass avatars.
4.2
Physical objects should not persistently follow, track, or interfere with avatars who have not intentionally engaged with the system.
4.3
Objects entering physical state should do so only as required for their intended function and should return to non-physical operation when appropriate.
CATEGORY 5 — LAND AND PARCEL RESPECT
5.1
Objects should check and respect parcel permissions before performing actions that affect the parcel or surrounding environment.
5.2
Objects should avoid behaviors that unnecessarily consume shared parcel resources or create avoidable operational burden on spaces the owner does not control.
5.3
Objects should provide a reasonable mechanism for owners to cleanly remove associated components and temporary objects from a parcel.
5.4
Objects must not modify parcel settings, environment settings, or access controls without explicit owner authorization.
CATEGORY 6 — LISTENER HYGIENE
6.1
All llListen calls should be paired with corresponding llListenRemove calls when listeners are no longer needed.
6.2
Listen channels should avoid trivial or easily guessed values. Session-specific or randomized channels are encouraged where practical.
6.3
Listeners must verify sender identity before acting on privileged commands.
6.4
Listeners should not persist indefinitely without operational justification or timeout handling.
CATEGORY 7 — PERFORMANCE AND RESOURCE STEWARDSHIP
7.1
Scripts should avoid unnecessary llSleep usage within event handlers where cleaner event-driven alternatives exist.
7.2
Busy-wait loops, unnecessarily rapid timers, and wasteful polling behavior should be avoided wherever practical.
7.3
Scripts should be designed to minimize unnecessary memory usage and avoid redundant computation within frequently executed functions.
7.4
Sensor sweeps and scanning operations should operate at intervals appropriate to their intended purpose.
7.5
External requests, HTTP calls, and remote service interactions should remain proportionate to legitimate operational needs.
CATEGORY 8 — TRANSPARENCY
8.1
Products built to this standard should include documentation describing behavior, permissions, configuration, and owner-accessible controls.
8.2
Products should clearly identify the creator and provide a reasonable support contact mechanism.
8.3
Products interacting with avatars or environments in non-obvious ways should document those behaviors clearly for owners.
8.4
Permissions should be set intentionally and consistently across objects, scripts, and included assets.
APPLICABILITY
Not every category applies equally to every product.
A static decorative object with no scripts does not meaningfully implicate listener hygiene or autonomous object rezzing. Certification review evaluates applicable categories according to the operational scope and intended behavior of the submitted product.
Categories determined not applicable during review may be noted accordingly within certification records.
VERSIONING
This standard is version 2.0.
AGP may continue evolving as Second Life scripting capabilities, shared-space practices, and virtual infrastructure expectations develop over time.
Products certified under a specific version remain certified under that version unless voluntarily resubmitted or materially altered.
CERTIFICATION
Products may be submitted for Structür AGP Certification review.
Certified products receive:
- a unique Certification ID
- official AGP certification badge assets
- public registry listing
- QR-verifiable certification status
Certification confirms that a product was reviewed against the applicable requirements of this standard at the time certification was granted.
PUBLIC REGISTRY
The Structür AGP Registry is publicly available at:
The registry maintains current certification records, certification status information, and verification data for AGP-certified products.
PHILOSOPHY
Responsible design is good design.
Shared virtual spaces function best when the systems operating within them are designed with genuine care for the people and environments around them.
Thoughtful engineering creates healthier communities.
Healthier communities make more ambitious creativity possible.
And better systems make shared worlds better places to inhabit.
Structür — Spaces. Stages. Systems.
Because thoughtful systems behave thoughtfully.