v0.4 — Add Agent Action Boundary before Execution Boundary#16
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR introduces an Agent Action Boundary that interprets and evaluates the legitimacy of requested actions before repository mutations reach the execution boundary.
Previously, the DevWedge evaluated only repository mutations (diff surfaces).
This change adds a pre-execution interpretive stage that evaluates:
actor identity
signal surface trust tier
requested action type
required authority
before mutation classification occurs.
This establishes a two-stage interpretation model:
Signal
↓
Agent Action Boundary
↓
Action Decision Artifact
↓
Execution Boundary
↓
Mutation Classification
↓
Meaning Artifact
Key Capabilities Added
Action Classification
Introduces deterministic classification of requested actions such as:
package.publishrelease.createworkflow.modifydependency.modifySignal Surface Trust Evaluation
Signal surfaces are evaluated using a registry:
Examples:
Actor Profile Resolution
Actor identities are resolved using a catalog that defines:
actor type
identity confidence
maximum authority
allowed intents
forbidden actions
Action Legitimacy Decision
Actions are evaluated against:
actor authority envelope
signal trust tier
declared intent
required authority
Possible outcomes:
allow
deny
escalate
advisory
Action Decision Artifact
The action boundary emits a structured artifact describing the interpretation result:
action_decision_artifact.json
This artifact records:
actor identity
signal surface
requested action
decision outcome
evaluation reasons
Example Interpretations
Denied
Action: package.publish
Signal: github.issue.title
Actor: automation
Decision: deny
Reason: ACTOR_FORBIDDEN_ACTION
Allowed
Action: release.create
Signal: github.release.metadata
Actor: maintainer
Decision: allow
Execution proceeds to the mutation boundary.
Canon Updates
This PR also introduces canonical schemas for the new interpretation artifacts:
sp.action_decision_artifact.v1
sp.actor_profile.v1
sp.agent_action_request.v1
sp.signal_surface_catalog.v1
These schemas define the governance structure for action boundary interpretation.
Architectural Impact
This PR expands DevWedge from a single mutation boundary to a two-stage interpretive boundary:
Agent Action Boundary
↓
Execution Boundary
This enables deterministic interpretation of both:
actions proposed by automation
repository mutations produced by those actions
Status
DevWedge prototype now demonstrates:
agent action boundary
execution boundary
signal surface trust tiers
actor authority envelopes
deterministic legitimacy evaluation
structured interpretation artifacts
Why This Matters
Automation and AI agents increasingly propose actions:
publishing packages
triggering releases
modifying CI workflows
We typically inspect what changed.
We rarely interpret whether the action itself was legitimate.
This change introduces an interpretive boundary between signals and execution, enabling deterministic legitimacy evaluation before automation actions proceed.