> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sharedgraph.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Lifecycle and safety

> Retire stale authority and publish only currently admitted network views.

A participating application must honor network blocks, moderation, deletion and grant lifecycle across every signed-in surface. A local hide only suppresses presentation within your application; it is not a network block. Public availability does not guarantee confidentiality or permanent availability.

## Conformance rules

* Never retry an authorized refusal as an anonymous read inside a signed-in experience. Invalid bearer credentials do not become anonymous access.
* Stop protected publication when current authority or restriction proof is unavailable. Clear protected results and retire stale sessions instead of continuing from cached content.
* Do not serve stale replicas of canonical posts, profiles or social relationships. Revalidate before display; events and reconciliation support updating your view, not a license to ignore current admission. Do not use session-storage read replication to arbitrate refresh.
* Honor deleted and unavailable representations without reproducing the removed body. Do not restore content from an application cache after a network removal.

| Change | Required client reaction |
| - | - |
| Grant revoked or replaced | Retire that grant's application session and require fresh authorization. A new grant is a new authority context. |
| Account deleted or suspended | Stop acting and publishing protected views for that account; discard stale authority. |
| Application suspended | Stop using its grants; surface the refusal and do not bypass suspension through another access tier. |
| Post deleted or moderation makes it unavailable | Remove its body from rendered/cached views. Preserve only the allowed tombstone or unavailable representation. |
| Network block | Revalidate interaction and presentation under the user's current safety view. Do not reconstruct hidden relationships from anonymous results. |
| Recovery or unavailable restriction proof | Suppress protected results until current authority and publication admission can be established again. |

Reinstatement does not justify replaying a previously admitted body without current validation. Logout from an application ends its local session; user-controlled network grant revocation is a distinct lifecycle action.

## Generation, incarnation and publication

Core admitted reads, including `/api/session`, carry `x-sharedgraph-incarnation`, `x-sharedgraph-revision` and `x-sharedgraph-witness-epoch`. Validate their syntax and preserve their association with the original response body. Missing or malformed stamps mean publication is unavailable, not that validation can be skipped.

`x-sharedgraph-incarnation` identifies the recovery incarnation. An incarnation change invalidates the prior publication context; revalidate and retire stale authority. `x-sharedgraph-witness-epoch` records independent restriction admission. Buffer a protected read, revalidate `/api/session`, and compare incarnation and witness epoch before releasing the body. Suppress it if either changed. `x-sharedgraph-revision` must be a valid nonnegative integer; do not require equality across unrelated requests, because unrelated bookkeeping can advance it.

The starter returns its browser generation in the JSON body of its own `/session`. The browser echoes it as `x-app-generation` on `/network/*`. A mismatch returns HTTP 409 and requires session revalidation. This is an application session signal, **not a core response header** and not a substitute for canonical grant or publication checks. Clear protected browser state when the session changes or validation becomes unavailable; revalidate when a hidden page returns. The starter revalidates active authority every four minutes and polls durable events every 15 seconds while visible and online. Known changes discard protected views before revalidation; offline, pagehide and freeze also clear them.

## Safe mutation retries

Every social mutation carries `intentId` in its JSON body: 1–100 ASCII letters, digits, underscores or hyphens. Generate one identifier per deliberate action and retain it for uncertain retries. There is no `Idempotency-Key` header in this contract.

Retry the **same method, path and body** under the same grant with the original identifier. The network stores a receipt per grant and intent and replays an admitted receipt rather than repeating the effect. Reusing the identifier for a different request returns HTTP 409 `intent_conflict`. Use a new identifier for a new action, never to blindly repeat an uncertain action. Receipts remain subject to current authority and availability; they are not reusable protected read views.

An edit also requires the current post `revision`. On `revision_conflict`, fetch the current admitted post and let the user reconcile the edit before submitting a new action. Successful mutations still need final principal and local session admission before returning their receipt. Never automatically retry writes after a network failure. If your UI offers explicit retry, preserve the intent separately from protected rendered content.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.