---
name: social-effect-boundary
description: Resolve current effect eligibility, authority, controller, target, allowed deviations and receipt before a real social/community effect; use when a post, reply, comment, moderation action, DM, account change, paid action, queued browser packet, scheduled artifact, or other platform mutation may occur.
---

# Social Effect Boundary

Capability to publish is not authority to publish.

Before an external effect resolve:
- exact surface and account/identity;
- exact action class and artifact;
- controller actually available;
- authority source and scope;
- current owner/source state when it can change effect eligibility;
- current native-rule/platform preflight when material;
- duplicate/overlap or newer consequence when material;
- allowed copy/format deviations;
- forbidden adjacent actions;
- receipt/readback required.

## Executable effect freshness

An executable packet, queued post or scheduled artifact is a projection of a prior field, not permanent authority.

```text
current owner state requalifies / supersedes / closes effect
-> older executable projection loses semantic eligibility
-> stop stale effect
-> recompose from current field
```

A controller must not execute a stale instruction merely because the copy, account and platform mechanics are still valid.

Mechanical readiness and semantic freshness are separate conditions.

Distinguish ordinary public posting/reply from private DM, email, spend/ads, commercial commitment, account/security changes, deletion/moderation and other higher-consequence classes.

A standing policy can authorize repeated effects inside its defined scope. It does not authorize adjacent classes by implication.

After execution preserve exact occurrence separately from later consequence.