🔀 What If a Conversation Could Reach a Clear State Without Letting Message Order Decide?

Turning Conversation Evidence into a Clear, Verifiable State

💬 ORL-Chat

A conversation can become difficult to follow surprisingly quickly.

Someone makes a proposal.

Another person changes it.

A third person objects.

Someone else endorses the amended version.

The original proposal may later be withdrawn.

The same action may be copied through more than one system.

Some messages may arrive late.

Some may arrive in a different order.

At that point, a simple question becomes difficult:

What is the current declared state of the conversation?

Should the answer depend on which message happened to arrive first?

Should a later network delay make an earlier proposal appear current?

Should the same action reported by two sources count twice?

Should missing information be guessed?

Should conflicting proposals be silently forced into one answer?

ORL-Chat explores a different approach.

It resolves a bounded conversation state from validated, structured conversation evidence.

The central idea is:

same admitted conversation evidence + same declared conditions -> same bounded state or the same defined refusal

Message arrival order and wall-clock timestamps are not treated as the authority that selects the result.

💡 The Central Idea

Most conversation systems display messages as a timeline.

That is useful for reading.

But a timeline does not always answer structural questions such as:

Which proposal is still active?
Was the proposal amended?
Was it withdrawn?
Has the required support been recorded?
Is there an unresolved objection?
Is important evidence missing?
Do two active proposals conflict?
Has the declared evidence boundary been completed?

ORL-Chat does not attempt to understand unrestricted human language.

Instead, it works with explicitly declared conversation actions and relationships.

The current supported action types are:

PROPOSE
AMEND
WITHDRAW
ENDORSE
OBJECT

The resolver examines how these actions relate to one another and derives the current bounded state.

🗣️ A Simple Example

Imagine a team discussing a meeting time.

The conversation contains these actions:

Proposal A -> Meet at 4 PM

Then:

Amendment B -> Change the meeting to 5 PM

Then:

Endorsement C -> Support Amendment B

The messages might appear in different orders on different systems.

One system may receive the endorsement before receiving the amendment.

Another may receive the original proposal last.

A third may receive duplicate copies of the same amendment.

ORL-Chat does not decide the result by asking:

Which record arrived first?

It asks:

What valid actions are present?
Which action targets which earlier action?
Which proposal remains active?
Which participation rule applies?
Are there conflicts or missing dependencies?
Is the evidence boundary open or sealed?

Once the admitted structure and declared conditions are the same, the bounded result is the same.

🧭 Three Conversation Outcomes and One Refusal Path

ORL-Chat does not force every conversation into a final answer.

It preserves three conversation outcomes and one refusal path.

`RESOLVED`

A topic becomes RESOLVED when exactly one supported active proposal remains and the declared participation conditions are satisfied.

For example:

proposal + valid amendment + required endorsement -> RESOLVED

The resolver can identify the active proposal and the declared value associated with it.

`INCOMPLETE`

A topic becomes INCOMPLETE when the admitted structure is valid but does not yet contain enough evidence for resolution.

Examples include:

a referenced proposal is missing
a required endorser has not endorsed
a participation threshold has not been met
no active proposal remains available for selection

ORL-Chat does not invent the missing action.

Missing structure remains visible as missing structure.

`ABSTAIN`

A topic becomes ABSTAIN when the admitted evidence contains a bounded conflict that prevents one clear result.

Examples include:

more than one active proposal remains
participant signals conflict
an active proposal is objected to
the dependency structure contains a supported cycle

The resolver does not silently select whichever conflicting action appeared first.

Conflicting structure remains explicit.

`REFUSED`

Invalid input is rejected before topic resolution.

Malformed JSON, duplicate JSON keys, floating-point values, and other strict-intake violations are refused before a conversation document exists.

Inputs that pass strict intake but violate the supported structural contract can produce a canonical REFUSED result.

Examples include:

unsupported fields
conflicting reuse of an action identity
cross-conversation references
invalid relationships
resource-limit violations

The principle is:

invalid or resource-invalid structure -> refusal before topic resolution

A refusal is not the same as an unresolved conversation.

It means the supplied input was not admitted into the supported conversation model.

🔀 Arrival Order Is Not Resolution Authority

Messages still arrive in an order.

Networks still have delays.

Applications still show timelines.

Logs still preserve chronology.

ORL-Chat does not claim that order and time are unnecessary in communication systems.

It makes a narrower distinction:

message arrival order != conversation-state resolution authority

The resolver derives its result from the admitted canonical relationship graph rather than replaying the conversation as a timeline.

Conceptually:

raw evidence -> strict intake -> canonical actions -> relationship graph -> active proposal frontier -> participation evaluation -> bounded result

Different systems may temporarily hold different evidence and therefore produce different local states.

ORL-Chat does not claim:

different evidence -> same result

Its claim begins when the bounded admitted evidence and governing conditions become equal:

same admitted structure + same declared contract -> same bounded result

♻️ Repeated Observation Is Not Repeated Action

The same conversational action may be reported by more than one source.

For example, two systems may both record the same proposal.

That should not automatically turn one proposal into two competing proposals.

ORL-Chat separates the observation from the underlying action:

observation multiplicity != action multiplicity

An observation can preserve where the evidence was seen.

The canonical action represents the bounded conversational action itself.

Exact duplicates can therefore be absorbed without multiplying the action being resolved.

This preserves provenance while preventing repeated evidence from silently changing the conversation state.

🔗 Relationships Matter More Than Position

A message saying “I agree” is not structurally complete unless the system knows what is being endorsed.

A message saying “replace that” is not structurally complete unless the target is declared.

ORL-Chat therefore evaluates explicit relationships.

An AMEND action targets an earlier supported action.

A WITHDRAW action identifies the action being withdrawn.

An ENDORSE action identifies the proposal being supported.

An OBJECT action identifies the proposal being opposed.

This allows the resolver to distinguish:

presentation text != action identity

The human-readable presentation can remain available in the private reconstruction bundle.

But the bounded result is derived from the declared typed structure.

👥 Different Conversations May Require Different Participation Rules

Not every conversation uses the same decision condition.

Some topics may require no endorsement.

Some may require one named supporter.

Some may require all declared participants.

Some may require an exact set of endorsers.

Others may require a declared threshold.

ORL-Chat supports participation profiles including:

NO_ENDORSEMENT_REQUIRED
SINGLE_DECLARED_ENDORSER
ALL_DECLARED_PARTICIPANTS
EXACT_DECLARED_PARTICIPANT_SET
DECLARED_THRESHOLD

This means that the same proposal evidence may resolve differently under different declared participation rules.

That is not inconsistency.

It is a declared difference in the governing contract.

same evidence + different participation profile -> potentially different bounded result

These profiles evaluate declared evidence only.

They do not authenticate people, prove consent, or establish legal agreement.

🔒 OPEN and SEALED Evidence Boundaries

A current conversation state may be calculated while more evidence could still arrive.

ORL-Chat therefore keeps evidence-boundary status separate from topic resolution.

The current boundary states include:

OPEN
SEALED

OPEN means the observed evidence set has not been declared complete.

SEALED means the declared expected observation references match the observed set for that bounded evaluation.

But:

SEALED != proof that no other message exists

SEALED != legal finality

SEALED != universal completeness

It is a declaration about the bounded evidence set being evaluated.

This separation matters because a topic state and an evidence boundary answer different questions.

topic resolution != evidence-boundary closure

🧾 A Result Should Carry Evidence

ORL-Chat does not return only a label such as:

RESOLVED

It can also produce structured evidence explaining how that result was derived.

The current architecture separates:

Public receipt

A public receipt provides a portable structural summary without carrying raw presentation text or raw declared values.

Private reconstruction bundle

A private bundle retains the admitted observations, presentations, declared values, graph structure, witnesses, and reconstruction material.

This gives two different sharing surfaces:

public structural summary

and:

private reconstruction evidence

Both declare:

execution_authority = NONE

A resolved conversation state does not automatically authorize a downstream action.

📦 Conversation-State Capsules

One of the major additions in ORL-Chat v2.0.0 is the Conversation-State Capsule.

A capsule is a portable, privacy-separated state derived from a verified private bundle.

The basic relation is:

verified private bundle -> structural identities + committed values + witnesses -> capsule

A capsule may carry:

the bounded state
the reason for that state
active-frontier identities
evidence coverage
boundary status
deterministic commitments to declared values

But it does not carry:

raw message presentations
raw declared values
participant names
observation sources
action references

This allows a bounded conversation state to be inspected or compared without automatically exposing the complete underlying conversation.

A value commitment is not encryption.

Low-entropy values may still be guessable.

Every capsule also declares:

execution_authority = NONE

🔄 Comparing Conversation States

Conversation-State Capsules can be compared.

The comparison is directional:

compare(left, right) -> relation of right to left

Possible relations include:

`IDENTICAL`

Both canonical capsule identities match.

`COMPATIBLE`

The declared comparison context matches, and the common resolved topics do not diverge.

`SUPERSEDES`

The right capsule contains a strict structural extension that changes the bounded state without producing a conflicting resolved value.

`DIVERGES`

A shared topic resolves to a different declared-value commitment.

`INCOMPARABLE`

The declared comparison contexts differ.

`UNSUPPORTED`

At least one capsule fails structural verification.

These are bounded structural relationships.

They are not universal judgments about truth, chronology, legality, consensus, or meaning.

🖼️ ORL-Chat Structural Overview

ORL-Chat Structural Overview — validated conversation evidence becomes canonical observations and actions, explicit relationships form a bounded graph, participation and boundary conditions are evaluated, and the result becomes a public receipt, private reconstruction bundle, and optional Conversation-State Capsule.

🛡️ Strict Input Boundaries

Determinism begins before resolution.

If two implementations admit different input structures, they may produce different results even when they appear to receive the same file.

ORL-Chat therefore defines strict intake rules including:

strict UTF-8 JSON
duplicate-key refusal
floating-number refusal
NaN and infinity refusal
exact interoperable integer limits
fixed supported field sets
bounded identifiers and text
bounded observations and participants
bounded input size
bounded graph depth
exact Unicode scalar-sequence handling

The current graph-depth limit is:

MAX_GRAPH_DEPTH = 256

A supported dependency chain within the limit can be evaluated.

A chain that exceeds the declared limit is refused deterministically.

This keeps resource limits inside the declared contract rather than treating them as hidden implementation details.

🔤 Exact Text Handling

Text processing can vary across runtimes and Unicode versions.

ORL-Chat v2.0.0 declares an exact Unicode scalar-sequence profile:

ORL-CHAT-UNICODE-SCALAR-EXACT-2-D01

Strings are preserved as exact sequences of Unicode scalar values.

That means canonically similar-looking strings remain different when their code-point sequences are different.

For example:

"café" != "cafe\u0301"

This is intentional.

ORL-Chat does not silently normalize one sequence into another.

The same explicit text rules are implemented across the Python producer, independent Python verifier, and JavaScript resolver.

🔍 Separate Verification Paths

The current release includes:

a Python reference kernel
a separately implemented Python verifier
a separately implemented JavaScript resolver
browser laboratories
frozen conversation corpora
cross-language parity vectors
seeded generated-property testing
hostile-input fixtures
falsification fixtures
capsule verification and comparison
automated GitHub Actions verification

The separate Python verifier does not import the producer reference kernel.

The Python and JavaScript implementations are also checked against shared parity evidence.

This creates more than one path for reconstructing and checking the declared result.

✅ Current Verification Evidence

ORL-Chat v2.0.0 currently reports:

2955/2955 PASS — Python reference kernel

173/173 PASS — independent Python verifier

13/13 PASS — frozen Python corpus

442/442 PASS — JavaScript resolver and cross-language parity

17/17 PARITY — live Python-JavaScript bundle comparison

8/8 PARSER PARITY — strict-parser comparison

256/256 PASS — generated-property assertions

154/154 PASS — adversarial assurance

310/310 PASS — capsule cross-language parity

The selected verification-critical files also pass the published SHA-256 checkpoint, and the automated workflow runs the complete suite on Ubuntu.

These results apply only to the declared v2.0.0 schemas, profiles, corpora, limits, implementations, and verification artifacts.

They are not independent third-party certification.

⚖️ What ORL-Chat Does Not Claim

ORL-Chat is not:

a replacement for a chat application
a messaging network
a consensus protocol
a legal agreement engine
a moderation system
an unrestricted language-understanding system
an identity-verification system
an authorization engine
an execution system

It does not establish:

factual truth
participant identity
source authenticity
authenticated consent
message delivery
legal validity
universal consensus
execution authority
safety of an instruction
completeness outside the declared evidence boundary

A RESOLVED value means:

The admitted bounded structure satisfies the declared resolver contract.

It does not automatically mean:

The value is true, authorized, safe, lawful, or suitable for execution.

🌱 Why This Direction May Matter

Many systems collapse several different questions into one apparent conversation result:

What actions were observed?
Are some observations duplicates?
Which proposal is active?
Was it amended?
Was it withdrawn?
Has it been endorsed?
Has it been objected to?
Are required relationships missing?
Is more than one active proposal present?
Has the declared participation condition been met?
Is the evidence boundary open or sealed?
Is anyone authorized to act?

ORL-Chat keeps these questions separate.

observation != action

conversation state != evidence-boundary closure

resolution != authentication

resolution != consent

resolution != authorization

resolution != execution

That separation may be useful in areas such as:

multi-system conversation reconstruction
delayed evidence synchronization
human and AI collaboration
structured approval discussions
disconnected or intermittently connected systems
audit reconstruction
portable decision receipts
privacy-separated state exchange
deterministic comparison between conversation states

Any real deployment would still require appropriate controls for identity, security, permissions, governance, transport, and execution.

🌐 Explore ORL-Chat

The ORL-Chat repository contains the current reference implementations, browser laboratories, verification tools, frozen corpora, hostile-input fixtures, Conversation-State Capsules, documentation, and checksum evidence.

🔗 GitHub repository: ORL-Chat

🧭 Structural Laboratory: Launch ORL-Chat Structural Laboratory

📦 Capsule Laboratory: Launch Conversation-State Capsule Laboratory

The repository remains the authoritative source for the current implementation, verification evidence, limitations, and license terms.

✍️ Authorship & Disclaimer

ORL-Chat is developed within the Shunyaya Framework.

It is a bounded reference architecture and implementation for deterministic conversation-evidence reconciliation.

It is not a legal, identity, authorization, consensus, moderation, or execution authority.

The reference implementation and associated verification artifacts may be used, copied, modified, tested, studied, and redistributed without a license fee, subject to the repository license terms.

Documentation, architecture materials, specifications, diagrams, and explanatory content are subject to the separate terms stated in the repository LICENSE.

⭐ The Idea in Simple Terms

A conversation may contain proposals, changes, withdrawals, support, objections, duplicates, missing evidence, and conflicts.

ORL-Chat turns the admitted structure of that conversation into three explicit conversation outcomes — or follows a defined refusal path when the input cannot be admitted:

RESOLVED

INCOMPLETE

ABSTAIN

or:

REFUSED

It does not let message arrival order or wall-clock timestamps silently decide which proposal wins.

When the admitted conversation structure and declared conditions are the same, the bounded result is the same — or the input is refused in the same defined way.

OMP