Receipts and Proofs ​

In coordination systems it is too easy to use the word “confirmation” as if it were universal. For Realith, that is not enough.

Several different things must be distinguished here, because each answers its own question.

Receipt ​

A receipt confirms a limited fact of servicing.

It may mean that:

• material was accepted;
• an operation was placed into processing;
• replication was performed;
• a refusal was formalized with a reason.

But a receipt does not automatically mean:

• that the object was recognized by the canon;
• that the subject obtained a right to the content;
• that an external addressee read or accepted the content;
• that the operator guarantees any future service.

Proof ​

A proof confirms one specific aspect.

For example, it may link a receipt to an event, confirm the inclusion of material into the network's working surface, link a transition to a published outcome, or confirm compliance with a certain policy condition.

A proof does not answer the question “is everything true in general?” It always confirms a limited aspect.

Proof Package ​

A Proof Package is needed when not one fact is required, but a composite chain of verifiable links.

For example, for one action it may be necessary to establish that:

• the subject initiated the step;
• the material was accepted;
• it was stored;
• the transition entered the canon;
• the network period outcome was published.

A proof package assembles such a chain, but it does not cancel the limits of each element included in it.

What must not be collapsed ​

A receipt must not be presented as a canonical outcome.

A Transport Confirmation must not be presented as recognition of state.

A proof package must not be presented as a right to content.

A published network outcome must not be presented as a service promise.

This distinction prevents the operator's service log from presenting itself as the canon itself and prevents participants from confusing the fact that a message was accepted with recognition of current state.