Institutional Feedback and Support Primitives

This document defines the foundation for the next generation of generic primitives ICN core will eventually model:

• Institutional feedback primitives — InstitutionalSignal, SignalRule, EscalationPolicy, MemberSignal, SignalPolarity.
• Member-facing read primitives — /me/standing (landed, #1627), /me/action-cards (landed, #1659; three of five source paths proof-bearing — signal_rule and obligation_lifecycle remain RFC-gated under #1646).
• Authority primitives — RoleAssignment.authority_scope (landed), TemporaryAuthorityGrant (future).
• Governed indicator primitive — Indicator with definition, owner, caveats, review interval, challenge path.
• Resource governance primitives — Obligation, Allocation, Settlement, Position, Unit, SettlementAsset.
• Support primitives — package-declared support programs and service relationships, expressed via existing Program / Structure / Activity / future Obligation.

None of these are implemented in this PR. The point is to fix doctrine before the runtime so that, when each primitive lands, it is member-originated where it should be, scoped where it should be, expiring where it should be, receipted everywhere, and contestable by the people it acts on.

Core stance

We are not building dashboards. We are building generic, reusable plumbing for institutional life:

• Standing tells members where they are.
• Action cards tell them what needs them.
• Signals tell the institution where it hurts — and where it's working.
• Member-originated signals let reality travel upward from below, not just downward.
• Temporary authority makes scoped, expiring, reviewable power-extension visible.
• Indicators make metrics governable and challengeable.
• Receipts prove legitimacy.
• CCL expresses institutional rules.
• Rust host runtime executes and stores generic lifecycle transitions.
• Institution packages define local meaning without poisoning the substrate.

If a future PR adds a primitive that doesn't earn its keep across at least two unrelated institutions, it belongs in an institution package, not in core.

Design influences

The doctrine here owes specific debts to four traditions. They are influences on shape, not product language. No ICN core primitive is named after any of them. Substrate types stay boring and reusable: InstitutionalSignal, SignalPolarity, Indicator, TemporaryAuthorityGrant, Obligation, Allocation, Settlement, Position. There is no Cybernetic*, no Mondragon*, no NervousSystem* in core, ever.

The anti-patterns each tradition refuses are folded into §9 (hard rules); they are not a separate ontology.

1. Recursive autonomy

ICN's entity / structure / activity / program / federation graph is the substrate's expression of recursive autonomy: each layer has its own decision authority and its own coordination obligations to the layers above and below.

Doctrinal rules for recursive autonomy

1. Local action is the default. A primitive that requires federation-level approval to do anything is a coordination smell.
2. Escalation must be explicit. A federation never automatically pre-empts a cooperative's autonomy — it must traverse a defined escalation path with receipts.
3. Federation coordinates only what cannot be coordinated locally. Treasury policy, charter conflicts, inter-cooperative settlement, federation-level legitimacy challenges. Not "everything."
4. Recursion all the way down. A federation of federations works the same way. No special "top" layer.

Why ICN is coordination plumbing, not a control panel

ICN's job is to provide the wiring that lets each layer of an institution function with its own authority while staying coordinated with the layers around it:

• the standing, role, and authority surface that lets each part know who it is;
• the signal and escalation surface that lets institutional feedback travel between layers;
• the receipt / decision surface that proves the response was legitimate;
• the contestation surface that lets a member challenge a metric or decision aimed at them.

Not in scope for ICN core, ever: a "control panel for the federation president." A federation that needs one has misunderstood what federation is.

2. Institutional signals (future generic primitive)

Institutional feedback should be visible, routable, and receipted — not buried in private channels and not centralized in a dashboard.

An InstitutionalSignal is a generic, future record that says: "something at this scope crossed a threshold or was raised by a member, and it needs attention." It is not yet implemented.

Sketch of the future shape (illustrative — not a contract)

InstitutionalSignal
├── id
├── domain_id            (governance domain)
├── source               (rule | member | external_observer | scheduled)
├── kind                 (opaque string — "blocked_work", "accessibility_concern",
│                         "obligation_overdue", "metric_challenge",
│                         "capacity_growing", "milestone_ahead", ...)
├── polarity             (positive | neutral | negative)   — see §2a
├── severity             (info | watch | concern | escalation | emergency)
├── confidence           (optional — how certain the source is)
├── actionability        (optional — informational | review_recommended | action_required)
├── opened_at, opened_by_did
├── closed_at, closed_by_decision_id  (decisions/receipts that resolved it)
├── escalation_state     (open | acknowledged | escalated | resolved | rejected)
├── related_refs         (proposals, structures, activities, role assignments)
└── receipts[]           (every state transition leaves one)

2a. SignalPolarity — feedback as sensation, not discipline

A signal carries a polarity field whose value is one of three:

This is a balanced-ternary feedback channel, not a pass/fail flag. Reading the substrate's signal stream should let a body see what's working, what's stable, and what's hurting in one view.

polarity is intentionally orthogonal to:

These four can co-vary in any combination. A polarity: positive signal can be severity: watch and actionability: review_recommended — "this is going well in a way worth examining and replicating." A polarity: negative signal can be severity: info and actionability: informational — "a small thing is degrading; nothing required, but on the record."

Doctrinal rules for polarity:

1. A negative signal is not punishment or discipline. A blocked-work signal, an overload signal, a legitimacy challenge — none of these target a person for sanction. They are sensation. The institution responds with a receipt and (if needed) an obligation, not a reprimand. Punishment lives in a different surface (governance proposals with explicit due process), and that surface must be reached through the same scoped, receipted, contestable path as any other governance act.
2. A positive signal can be actionable. actionability: review_recommended on a positive signal means "study this — it reveals a pattern worth replicating." Positive signals are not just morale boosters; they are how the substrate lets institutional learning travel as well as institutional pain.
3. Neutral is not silence. A neutral signal is the substrate saying "the threshold passed cleanly, on schedule, no surprises" — and that record is itself useful, especially when later questions ask "was this checkpoint actually met at the time?".
4. Polarity is the source's claim, not a verdict. A member-originated polarity: negative signal is the member's reading. The institution can resolve it with a receipt that disagrees, but the original polarity claim is preserved on the record. Erasing or overwriting a member's polarity is a substrate violation.
5. Member-originated signals carry polarity too. A worker raising "this onboarding flow worked beautifully" (positive) is as much a first-class signal as one raising "this onboarding flow blocked me" (negative). The substrate must not privilege complaint over praise — both are reality traveling upward.

Anti-patterns this field must refuse:

• Treating polarity: negative as an automatic discipline trigger.
• Hiding polarity: positive signals from the action-card surface (they belong there too, as recommended-review work).
• Collapsing polarity into severity (an "extra severity bit" loses the orthogonality this field exists for).
• Letting an institution package add polarity values like excellent, awful, mixed, etc. The set is exactly three. Local nuance lives in kind, not in polarity.

Sketch of SignalRule and EscalationPolicy

A SignalRule is a generic CCL-or-data trigger: "this state of affairs must raise a signal of this kind at this severity." The rule lives in the institution package; the runtime evaluates it.

An EscalationPolicy is a generic CCL-or-data routing table: "a signal of this kind at this severity, opened in this scope, escalates to this body within this window unless acknowledged."

What belongs where

How signals become action cards

A signal at the appropriate severity, scoped to a body the caller belongs to, surfaces in that caller's /me/action-cards (endpoint shipped in #1659; the signal_rule source path that emits these is RFC-gated under #1631, tracked by umbrella #1646) as something they're being asked to attend to. The signal record itself is the unit of institutional truth; the action card is the member-facing rendering.

Anti-patterns this primitive must refuse

• Signal-as-broadcast. A signal must have a defined target body, not just be screamed into the federation.
• Signal-as-ticket. Signals are not tickets. They're institutional pain. Closing one without a receipt is a violation.
• Severity inflation. Severity ladder must be defined; arbitrary "P0/P1" inflation defeats prioritization.

3. Member-originated signals

Information bottlenecks are political power. If only "the top" can sense, then "the top" owns reality. ICN must support member-originated feedback as first-class records — same shape, same escalation, same receipts as rule-originated signals — or the substrate becomes asymmetric.

ICN's signal subsystem is not purely top-down sensing. It must include MemberSignal — a signal opened by a member acting in their own DID, addressed to a body they belong to.

Examples (vocabulary owned by the institution package, not by ICN core)

Polarity in parentheses; vocabulary is illustrative.

• A member raises an accessibility concern about a venue or process. (negative)
• A worker raises a blocked-work signal because an upstream decision is overdue. (negative)
• A volunteer raises an overload signal because their committee can't absorb more. (negative)
• A member raises a legitimacy challenge against a decision they were excluded from. (negative)
• A member raises a metric challenge against an indicator they believe misrepresents reality (see §6). (negative)
• A member reports an onboarding-worked signal: a new member's first cycle landed cleanly and the flow is worth replicating. (positive)
• A peer mentor reports a capacity-growing signal: a co-op took on a working-group role earlier than expected. (positive)
• A scheduled checkpoint passed within tolerance — emitted by a rule, not a member, but still a record. (neutral)

Doctrine

• No surveillance-only sensing. If the only signals the substrate supports come from rules-on-state, the substrate is a panopticon.
• Member signals are first-class. Same record shape, same escalation, same receipts as rule-originated signals. Member signals carry polarity too — praise travels upward as cleanly as pain.
• Anonymous-but-authenticated must be a future option. A member should be able to raise a signal whose contents are visible and whose authorship is provable to a designated body without being publicly attributed. Out of scope for v1; design space reserved here.
• The institution must answer. A member-originated signal that escalates without acknowledgement crosses a defined window and creates an obligation on the receiving body. The receipt of that obligation is permanent.
• A member's polarity claim is preserved. The institution may resolve a polarity: negative signal with a receipt that disagrees, but the original polarity is on the record. Erasure is a substrate violation (see §2a).

What belongs where

4. Action cards

Action cards are not a new ontology. They are a rendering of institutional need that the caller can act on.

/v1/gov/me/standing (shipped, #1627) tells you who you are. /v1/gov/me/action-cards (shipped, #1659; signal_rule/obligation_lifecycle source paths still RFC-gated under #1646) tells you what needs you.

An action card is not a stored entity. It is a derived view computed from:

• the caller's StandingResponse;
• proposals in their domains where their vote is open;
• action items assigned to them or to a body they hold a role in;
• signals (§2/§3) targeted at a body they're a member of;
• temporary authority grants (§5) about to expire or pending review.

Why the card layer exists

• Reduces the cognitive cost of participation. A member should not have to traverse five endpoints to find the next thing.
• Makes the institution legible from below. Rendering need as cards puts the substrate in service of the member, not the other way around.
• Mobile-shaped. Cards are paginatable, dismissable, and addressable by a single tap. The desktop dashboard is a happy accident, not the design target.

Doctrinal rules

1. A card is a view, not a record. It points at a primitive. Closing a card means closing the underlying primitive (vote, action item, signal); the card disappears as a derived consequence.
2. No card without provenance. Every card carries the source primitive's id and the route to its detail and receipts.
3. Accessibility is a substrate concern. Card text, ordering, and interaction must be accessibility-first. ICN core defines the data shape; the institution package may shape the strings but not the structure.
4. No card invents authority. A card cannot grant authority the standing doesn't already imply.

Relationship to other primitives

• /me/standing is the source of truth for who you are.
• Action cards are the source of truth for what's currently asking for you.
• Receipts are the source of truth for what you and others have already done.
• Signals are the source of truth for where the institution hurts.

5. Temporary / emergency authority

The hardest historical lesson: emergency powers are not the problem. Permanent emergency powers are the problem.

A future TemporaryAuthorityGrant primitive will let a body extend a member's authority for a bounded purpose, with a defined expiry and a mandatory post-review.

Required properties

Doctrinal rules

1. No silent permanence. A grant that lapses without review leaves a record. Renewals are explicit, not automatic.
2. No invisible scope. A grant that names "trust the bearer" is rejected at construction.
3. Scope ≠ sovereignty. A grant cannot escalate a structure into an entity, cannot create new entities, cannot move treasury beyond the granted scope.
4. Crisis is not a license. The runtime treats severity = emergency signals the same way it treats other signals: through the same scoped, expiring, reviewed grant flow.

Relationship to today's authority surface

• RoleAssignment.authority_scope (now plumbed end-to-end via #1630) is the standing-grade authority surface.
• TemporaryAuthorityGrant will be the moment-grade authority surface.
• Both will roll into StandingResponse.authority_scopes, with provenance distinguishing standing vs grant.

6. Governed indicators / metric humility

Metrics are not reality. Treating them as reality is how dashboards become priesthoods.

A future Indicator primitive will let an institution publish a measurement with the structure required to govern it.

Required fields

Indicator
├── id
├── name                   (display)
├── definition             (precise — what is being counted, how, with what window)
├── owner                  (a structure or role — the body that maintains it)
├── caveats[]              (known reasons the number can mislead)
├── review_interval        (when the definition itself must be re-examined)
├── challenge_path         (link to the signal kind a member raises to dispute it)
└── current_value, samples[]

Doctrinal rules

1. Owner-required. An indicator with no body responsible for it does not get published.
2. Definition first. The raw number is meaningless without the definition; the runtime refuses to surface a value without one.
3. Caveats are first-class. An indicator without disclosed caveats is a propaganda surface.
4. A challengeable indicator. Every indicator must declare the signal kind a member uses to dispute it (linking back to §3). Unchallenged indicators rot into priestly facts.
5. Re-examination is scheduled, not optional. The runtime will eventually open a metric_review_due signal when a review_interval lapses.

What belongs where

Anti-patterns

• Dashboard priesthood: a screen of green numbers no member can dispute.
• Counter-as-truth: a metric whose definition is "what the counter happens to count today."
• Owner-less metric: a number nobody is responsible for.

7. Resource governance (future obligation / allocation / settlement primitive track)

Participatory budgeting works when members see the tradeoff and authorize it, not when they ratify a finished plan.

A future generic primitive set will let an institution model the lifecycle of resource flows in a regulatory-safe vocabulary:

Vocabulary discipline (regulatory-safe)

This is not a stylistic preference. It's a regulatory boundary. Hosting a "wallet" with a "currency balance" that processes "payments" pulls ICN deployments into a category the substrate must not be in. The vocabulary above keeps the lifecycle expressible without performing the regulated activity.

Why these are not in core today

The runtime would have to know what an "asset" is and how a "position" is computed. NYCN's sponsor/budget lifecycle is currently expressed in package data because the generic primitives don't yet exist. The graduation rule applies: only when a second institution's resource lifecycle has the same shape with different content does the primitive earn a place in core.

Doctrinal rules (anticipating the design)

1. No flow without authorization. An allocation without a governance receipt is rejected at construction.
2. No allocation without obligation or program ref. Resources don't move "for general purposes."
3. No settlement without a matching allocation. No after-the-fact reconciliation as the source of truth.
4. Receipts are immutable and form the primary audit chain.
5. Member-originated obligation challenges (§3) are first-class — "this obligation should not have been authorized" must be raisable.

8. Support-institution layer

A federation that invests only in governance and only in a treasury, and not in the support layer that reproduces it, runs out of capacity. Members burn out, new cooperatives never spin up, technical knowledge stays trapped in the few who hold it, and mutual aid happens informally and breaks under stress.

The substrate must make it possible for a federation to declare its support layer — education, onboarding, technical / legal / admin support, peer mentorship, mutual aid, shared services — without baking any specific federation's school, fund, or service into core.

What ICN core may eventually know

What ICN core will never know

• A primitive named MondragonSchool, Caja, Eroski, or any institution's named entity.
• A primitive named OrganizingCooperative, SupportFederation, SponsorTier.
• Any service catalog entry whose semantics are specific to one federation.

How a federation declares its support layer (today, with current primitives)

NYCN-style packages can already express most of the support layer using existing primitives:

• Support program = BootstrapProgramRecord { kind: Cycle | Custom("onboarding") | ... } parented to the support entity.
• Shared service = BootstrapStructureRecord { kind: Office | WorkingGroup } with a clear mandate.
• Education / onboarding cohort = BootstrapActivityRecord linked to a support program.
• Inter-cooperative solidarity = BootstrapEntityRecord { entity_type: federation, operating_purpose: "<institution-local>" } plus future obligation primitives.

The graduation rule for moving any of this into core: a second federation, unrelated to the first, must need the same shape with different content.

9. Anti-patterns (hard rules)

The following are forbidden in ICN core code review. Each one is a way the substrate could be corrupted into the thing it must not become.

10. Implementation backlog (foundation track)

This document is doctrine. Each section above implies one or more future runtime tracks. None of them land in this PR.

Companion follow-up issues

The following umbrella issues track the RFCs and design work each section above implies. They were opened together with this doc.

• #1608 — feat(gateway): implement GET /me/action-cards — standing-derived participation queue (§4).
• #1623 — persist standalone proposals/votes/delegations across gateway restart (cross-cutting; required before any of these primitives is meaningfully smoke-testable).
• #1631 — docs(rfc): institutional signals, escalation policies, and member-originated signals (§2 + §2a + §3). Includes the SignalPolarity ternary (positive | neutral | negative) as a first-class field, orthogonal to severity / confidence / actionability.
• #1632 — feat(governance): design temporary authority grants with expiry and post-review (§5).
• #1633 — docs(architecture): governed indicators and metric challenge paths (§6).
• #1634 — docs(rfc): obligation/allocation/settlement primitives (§7), explicitly using regulatory-safe vocabulary.
• #1635 — docs(architecture): support-institution package pattern for federations (§8).

The graduation rule from the boundary doc applies to every one of these: only land the runtime in ICN core when a second institution needs the same shape with different content.

Cross-references

• `INSTITUTION_PACKAGE_BOUNDARY.md` — what belongs in ICN vs what belongs in an institution package.
• `KERNEL_APP_SEPARATION.md` — the meaning firewall between kernel and app.
• `IDENTITY_MEMBERSHIP_ARCHITECTURE.md` — DID, membership, standing primitives.