Deterministic • Task-Bounded • Revalidation-Aware • Replay-Oriented
Structural Plugin is a deterministic reference architecture for governing capability visibility and task-specific digital action authority inside a declared mediated execution boundary.
Its central separation is:
capability != visibility != task authority != security authorization != execution
The current v0.3.0 implementation is a self-contained browser reference demonstration plus a separate Python verifier.
A real browser extension is a later integration direction.
The architecture is intended to remain broader than one extension runtime.
It explores the gap between broad software capability and narrow user task authority.
A system may be able to send, upload, delete, purchase, share, or change settings while the user's current instruction authorizes only reading or drafting.
The reference separates:
available capability > task-visible capability
and:
task-visible capability > admitted action authority
Keep software capable while structurally bounding what the task can see and what each resolved action may execute.
Boundary 1:
Capability Surface Resolver
It answers:
Should this capability enter the active task surface?
Boundary 2:
Action Authority Resolver
It answers:
Does this specific resolved action fit inside the active task authority?
AI agents and browser automation are strong application directions, but the architecture is not limited to AI.
A proposal may come from:
- an AI agent;
- browser automation;
- an extension;
- an application integration;
- another declared software actor.
The proposal source does not automatically become execution authority.
No.
It does not replace:
- authentication;
- application authorization;
- browser security;
- operating-system security;
- endpoint protection;
- network security;
- payment authorization;
- legal or organizational authority.
Its bounded question is:
Does this resolved action fit inside the currently declared task authority?
No.
It may complement prompt-injection defenses, but its central claim does not require perfect malicious-instruction classification.
For example:
instruction requests UPLOAD
active authority = READ_ONLY
therefore:
UPLOAD outside authority -> no admitted execution
The principle is:
instruction != authority
Capability means that the software or environment can technically perform an operation.
Capability existence does not determine whether the current task should see or use that operation.
Visibility describes whether a supported capability enters the active task surface.
Current conceptual states are:
VISIBLE
ISOLATED
DORMANT
FORBIDDEN
DEFERRED
BLOCKED
capability existence may remain constant while task visibility changes structurally
A capability does not have to be deleted from the software merely because the current task does not need it.
DORMANT means the capability exists but is not needed for the current task surface.
FORBIDDEN means the active task profile explicitly excludes the capability.
DEFERRED means the capability may become relevant after a later explicit authority expansion, but it is not active for the current task.
The current email reference uses:
SEND_EMAIL = DEFERRED
while the active task remains draft-only.
No.
The demonstration deliberately supports an unrestricted proposal path.
An out-of-surface proposal still passes through the Action Authority Resolver.
This tests:
least visibility != sole protection
It is the task-specific structural object that declares what actions and targets may execute under the current reference profile.
The current draft-only envelope admits:
READ_THREAD
CREATE_DRAFT
EDIT_DRAFT
and prohibits:
SEND_EMAIL
ADD_RECIPIENT
FORWARD_ATTACHMENT
UPLOAD_LOCAL_FILE
DELETE_MESSAGE
No.
SEND_EMAIL is incomplete without target, recipients, content, and other relevant structure.
The governing principle is:
same action name != same authority
It is the normalized action representation used by the resolver.
The current profile binds:
- proposal identity;
- action;
- target;
- subject;
- origin;
- destination;
- data set;
- recipient set;
- amount;
- unit;
- quantity;
- scope;
- action identity.
ADMITTED
ESCALATION_REQUIRED
REFUSED
UNSUPPORTED
STALE is a post-admission revalidation or disposition state, not an initial admission state.
REFUSED means the action conflicts with an explicit boundary in the current profile.
ESCALATION_REQUIRED means the action may be meaningful but exceeds the current envelope in a way the model treats as potentially expandable.
UNSUPPORTED means the active profile does not define the action class sufficiently for admission.
The safe relation is:
UNSUPPORTED != ADMITTED
Authority Delta identifies the authority required by the proposed action that is missing from the active envelope.
Delta_A = A_required - A_active
It allows a future interface to explain exactly what changed instead of asking for a broad new permission grant.
For example:
SEND_EMAIL -> DATA_EGRESS + SEND_COMMITMENT
No.
It is an explanation and comparison artifact.
It does not itself expand the active authority envelope.
Because digital actions often move information.
The action verb alone may not reveal:
- what data leaves the current context;
- where it goes;
- whether a new external recipient is introduced.
The current reference includes:
OBSERVE
PREPARE
MUTATE_REVERSIBLE
DISCLOSE
COMMIT
IRREVERSIBLE
Unsupported actions may resolve to:
UNCLASSIFIED
No.
The current model is a bounded reference vocabulary.
Future profiles may represent consequence across multiple dimensions.
Because state may change between preview and execution.
A recipient, file, target, origin, thread version, draft version, or other material dependency may change.
The principle is:
admission at preview time != permanent execution authority
STALE means the relevant current-state dependency commitment no longer matches the commitment used when the action was admitted.
The current state-drift demonstration preserves:
admission_state = ADMITTED
revalidation_state = STALE
observed_execution_state = STALE
No universal whole-state invalidation claim is made.
The current profile commits declared action-relevant dependencies.
A future profile may refine those dependencies further.
No.
Admission and execution remain separate.
The underlying application may reject the action, fail, or return an unknown result.
The current reference uses states including:
NOT_DISPATCHED
OBSERVED_COMPLETED
OBSERVED_FAILED
STALE
RESULT_UNKNOWN
No.
The current reference uses bounded simulated execution for the supported safe task path.
The higher-consequence actions are demonstrated through structural resolution and non-dispatch.
A receipt binds the supported decision and execution evidence for one governed proposal.
It includes identities and states for:
- task;
- capability surface;
- authority envelope;
- canonical action;
- target;
- data flow;
- consequence;
- authority delta;
- admission;
- revalidation;
- execution observation.
Yes.
A correct refusal can produce a valid receipt with:
Execution = NOT_DISPATCHED
Yes.
A correctly recorded stale action can belong to a verification bundle that passes reconstruction.
The verifier checks evidence consistency, not whether every action completed successfully.
The current SP-AUDIT-1-D02 suite covers:
- core canonical behavior;
- capability surface rules;
- action authority;
- revalidation;
- receipts;
- frozen vectors;
- verification behavior;
- permanent regressions.
Current result:
87/87 PASS
They are a committed 14-case decision corpus under:
SP-VECTORS-1-D01
Current vector-set identity:
vector_set_db8f530b88e4d68c97f8056c
For frozen vectors, it reconstructs supported decisions and identities.
For browser verification bundles, it checks and reconstructs:
- bundle root;
- profile identities;
- task identity;
- capability-surface identity;
- authority-envelope identity;
- entry count;
- entry identities;
- state chain;
- canonical action and decision reconstruction;
- revalidation outcome;
- receipt reconstruction;
- final execution-state binding.
No.
The verifier reconstructs the declared supported evidence.
No.
The current project demonstrates a separate Python implementation path and cross-implementation reconstruction for the tested corpus and bundles.
Third-party verification and certification are not claimed.
A valid stale bundle accurately records:
ADMITTED -> STALE -> STALE
and reconstructs consistently.
A tampered bundle changes committed evidence without recomputing the governed relations and is rejected.
87/87 PASS
Audit identity:
audit_d0a742e78f17101746a1a3b6
14/14 PASS
Vector-set identity:
vector_set_db8f530b88e4d68c97f8056c
bundle_77732628ebaa7306b94e4b33
bundle_57ad3c8ce0d12859488c85ef
Yes.
A deliberately modified safe bundle was rejected with failures including:
BUNDLE_ROOT_MISMATCH
ENTRY_2_ENTRY_IDENTITY_MISMATCH
ENTRY_2_DECISION_RECONSTRUCTION_MISMATCH
ENTRY_2_REVALIDATION_STATE_MISMATCH
ENTRY_2_REVALIDATION_REASON_MISMATCH
CAPS explores:
capability existence != automatic visibility
Structural Plugin uses that separation as its first boundary and adds a second boundary for specific digital action authority.
SERA governs bounded document mutation.
Structural Plugin governs broader digital action authority.
The shared discipline is that a proposal does not automatically become execution authority.
STRIDE separates proposed intention from bounded physical motion authority.
Structural Plugin applies an analogous authority-separation discipline to digital action while using its own action, target, data-flow, and evidence model.
It is compatible with least-authority thinking but explores a more explicit task-resolution path:
capability visibility
plus:
resolved action authority
plus:
current-state revalidation
plus:
reconstructable evidence
Within the declared reference profiles and tested cases, it demonstrates:
- deterministic capability-surface identities;
- deterministic canonical action identities;
- explicit action admission states;
- explicit authority deltas;
- data-flow resolution;
- consequence classification;
- current-state revalidation;
- explicit stale execution prevention;
- deterministic receipts;
- verification entries and bundle roots;
- 14 frozen decision vectors;
- separate Python reconstruction;
- tamper rejection.
It does not establish:
- control over every browser action;
- universal prompt-injection prevention;
- universal secure execution;
- endpoint integrity;
- browser integrity;
- universal application semantics;
- production readiness;
- third-party certification;
- third-party verification;
- legal authorization;
- regulatory compliance;
- universal usability superiority;
- universal performance superiority.
No production certification is claimed.
A production integration would require, where relevant:
- application-specific adapters;
- security review;
- browser-extension review;
- performance characterization;
- failure-mode testing;
- accessibility review;
- domain-specific action profiles;
- operational monitoring;
- further independent validation.
The strongest current bounded claim is:
Structural Plugin demonstrates a deterministic reference architecture in which task capability visibility and task-specific digital action authority remain separate, material state changes can invalidate previously admitted execution, and supported evidence can be reconstructed through a separate Python implementation path.