Published State Summaries

Overview

It is needed so that the canonical outcome can be used, verified, and passed forward without disclosing the entire internal array of the environment.

Without a published state summary, epochal architecture remains incomplete.

The network then either:

• forces participants to re-enter the internal history deeply every time;
• or leaves the current outcome without a compact verifiable form.

For Realith, that is undesirable.

What such a summary links together

A published state summary must link together:

• the previous verifiable outcome;
• the new epoch result;
• the volume of accepted transitions needed for verification of the next step;
• a verifiable surface sufficient for the next coordination;
• a reference to the boundary between the published outcome and unpublished internal content.

This is not a full log and not merely a technical receipt.

One more distinction must be retained here:

> a published state summary is not a new form of the object itself or of its state; it is an externalized verifiable form for an already canonized epoch result.

What it is not

A published state summary must not be confused with:

• an operator receipt;
• a separate proof;
• transport confirmation;
• the full internal state of a contour;
• the full history of an object.

It is a separate type of network artifact.

It is precisely through such a summary that one can reconcile:

• verifiability of outcome;
• limited observability;
• separation of working and archival roles;
• the possibility of external verification without access to the whole internal layer.

At the current stage, one should not assert:

• the final field composition;
• the final commitment format;
• the final cryptographic profile;
• the final composition of proof.

But it can already be asserted that without a compact published state summary, the epochal architecture of Realith remains incomplete.