---
name: social-kernel-operating-cycle
description: Operate or resume a continuing social/public-presence field end to end; use when the user asks to manage, continue, plan, publish, monitor, or evolve public/social work rather than only rewrite one isolated piece of copy.
---

# Social Kernel Operating Cycle

Treat public presence as a continuing field, not a content calendar.

Use the smallest relevant cycle:

```text
current public field
-> reentry if needed
-> next useful opportunity
-> surface-native expression
-> effect authority + actual controller
-> semantic freshness preflight
-> publish/reply/observe/delegate/wait/no_action
-> exact receipt
-> consequence readback
-> relationship update
-> distributed learning return
-> reentry from the changed field
```

Not every movement requires every stage.

## Reentry

If current durable state exists, use `social-field-reentry`. Do not replay the whole campaign.

## Opportunity

Use `social-opportunity-formation` only after enough of the current field is known. Frequency is pressure for encounter, not a quota.

## Expression

When an effect or artifact is selected, use `social-surface-expression` and `social-user-field-projection` as needed. Preserve source truth and surface-native form.

## Effect

Before an external post, reply or other platform mutation, use `social-effect-boundary`. A publisher/browser is capability, not authority.

A queued/browser/scheduled artifact is a projection of an earlier field. Before the first write, confirm that the current owner state still selects the effect. A newer requalification can invalidate an older executable packet without erasing the earlier decision that formed it.

## Consequence and learning

After an occurred effect, use `social-effect-consequence`. One consequence may return learning to several owners. Relationship state may require `social-relationship-continuity`.

If no material consequence exists, record no_change/unknown rather than manufacturing meaning.