⌨️ What If AI Could Propose a Document Edit Without Deciding What It Is Allowed to Change?
SERA — Where Humans and AI May Propose, Structure Resolves, and Admission Permits
AI systems are becoming increasingly capable of editing documents.
They can rewrite paragraphs.
Move sections.
Delete text.
Insert new content.
Apply patches across large files.
But this creates a deeper question:
Should the system proposing an edit also decide exactly what part of the document it is allowed to change?
SERA explores a different answer.
Anyone may propose. Structure resolves. Admission permits. Evidence records.
SERA stands for Structural Edit Resolution and Admission — the architecture explored in this project for separating edit proposals from structural target resolution and mutation authority.
🌐 Try the Live SERA Structural Keyboard Demo on GitHub pages
Explore structural navigation, human and AI edit proposals, admission, refusal, concurrency, and evidence directly in the browser.
💡 A Different Question About Document Editing
Most editing begins with a selection.
A human highlights some text.
An application receives a range.
An AI agent produces coordinates, a patch, or a replacement.
The change is then applied.
This works well when the target is correct.
But what happens when:
- the supplied range points to the wrong sentence;
- the document changes before the edit is committed;
- an AI proposal identifies the wrong structural unit;
- a narrow request results in a broader mutation;
- two edits interact with the same document at nearly the same time?
SERA asks a simpler but important question:
Before applying the edit, what does the document structure actually permit to change?
The central relation is:
proposal -> resolve -> plan -> preview -> revalidate -> admit -> execute OR refuse -> receipt
And the governing separation is:
proposal authority != target authority != mutation authority
In plain language:
Being allowed to suggest a change is not the same as being allowed to choose the target or mutate the document.
🧠 The Core Idea
Imagine asking an AI assistant:
Delete the second sentence of this paragraph.
The AI may understand the instruction correctly.
But instead of allowing the AI-generated character range to become the final authority, SERA can treat that supplied range as a hint.
The target is resolved from the current document structure.
The actual sentence is identified structurally rather than inherited automatically from the supplied range.
The exact edit is planned.
The user can preview it.
The relevant structure is checked again before commitment.
Only then can the mutation be admitted.
For strict machine proposals:
machine-supplied range = locator hint
not:
machine-supplied range = mutation authority
This creates a boundary between:
what was proposed
and:
what may actually change
🔒 No Silent Retarget
One of SERA’s central rules is simple:
An edit prepared for one target must not silently execute against another target.
If the target represented during preview is different when the edit is finally committed:
preview_target_fingerprint != commit_target_fingerprint -> no execution under old commitment
The old edit does not simply move to the newly resolved location.
Instead:
re-resolve -> new preview -> new commitment -> new admission
This is the No Silent Retarget principle.
The goal is not to force an edit to succeed.
The goal is to make incorrect authority fail visibly.
✅ Not Every Document Change Should Cancel Every Edit
There is another side to the problem.
Suppose an edit is prepared for paragraph five.
Someone then fixes a spelling mistake in paragraph one.
Should the prepared edit automatically become invalid?
Not necessarily.
SERA distinguishes the identity of the complete document from the structure that a particular edit actually depends on.
Conceptually:
document changed != proposal automatically stale
The governing idea is:
unrelated change -> authority may survive
relevant change -> authority must be re-established
SERA calls this Structural Admission Survival.
The aim is to avoid both extremes:
safe editing != accept everything
and:
safe editing != invalidate everything
Instead:
preserve authority only while the structure that justified it remains valid.
🛡️ Bounded Mutation Authority
Even after an edit is resolved and admitted, it should not receive unlimited permission to change the document.
SERA therefore uses a declared mutation boundary.
The governing relation is:
write_set(E_c) subseteq admitted_mutation_envelope
In simpler language:
The final edit may only write inside the boundary that was actually admitted.
If the plan attempts to escape that boundary:
plan escape -> CONFLICT
This is a structural form of least authority for editing.
A sentence deletion should receive the authority needed to delete that sentence.
Not the authority to rewrite the entire document.
🛑 Sometimes Refusing the Edit Is the Correct Result
SERA does not assume that every proposal must become an edit.
A target may be ambiguous.
The required structure may have changed.
The proposed mutation may exceed its allowed boundary.
The proposal may no longer mean what it meant when it was prepared.
In those situations, SERA can refuse.
A valid refusal preserves:
zero mutation + explicit state + declared reason + evidence
This means a refusal is not simply an error.
A refusal is a successful outcome when the proposed edit can no longer be safely resolved or admitted.
Sometimes the safest editing system is not the one that edits fastest.
It is the one that knows when not to edit.
🤖 Humans and AI Enter the Same Boundary
SERA does not create one editing rule for humans and another for AI.
A proposal may come from:
a human
an AI agent
an API
an automation layer
an assistive interface
The same basic path applies:
proposal -> resolution -> planning -> preview -> revalidation -> admission -> execution OR refusal -> evidence
The proposal source remains visible.
But the source does not automatically become target authority.
This separates:
model proposal quality != edit-admission correctness
A very capable AI can still propose the wrong target.
A simple human action can also become stale.
SERA governs the edit boundary rather than trusting the identity of the proposer.
⌨️ Structural Keyboard: The Human Reference Surface
SERA is the underlying edit-admission architecture.
Structural Keyboard is its current human-facing reference surface.
Its principle is:
Edit at the level you think.
Instead of working only with raw character positions, the reference interface allows editing through structural units such as:
grapheme
word
sentence
paragraph
and supported document structures.
The important idea is not merely easier selection.
The interface makes the authority chain visible:
proposal -> target -> plan -> admission -> bounded mutation -> evidence
SERA separates proposal, structural target resolution, planning, preview, commit-time admission, bounded mutation, refusal, and evidence so that the system proposing a change does not automatically receive authority over what part of the document is actually changed.
🌍 Why This Could Matter
AI-assisted editing is moving rapidly from simple suggestions toward direct document mutation.
That creates a new architectural question.
Should an AI-generated patch be trusted simply because it exists?
Should a range supplied by an automation system automatically become the executable target?
Should an edit remain valid after the structure it depended on has changed?
SERA explores a different model:
Let intelligence propose freely.
Let structure determine the target.
Let admission determine whether the prepared mutation is still valid.
Let execution remain bounded.
Let refusal remain explicit.
Let evidence record what happened.
The same idea may eventually be useful beyond ordinary document editing, including structured text, code-editing surfaces, APIs, automation systems, and assistive interfaces.
🧪 Current Reference Status
The current public reference release is SERA v0.9.2.
Its producer-side browser verification currently reports:
329/329 full release audit PASS
27/27 known regressions PASS
34/34 feature coverage PASS
766/766 frozen grapheme conformance PASS
The repository also includes a passing automated verification workflow.
These results are producer-side assurance.
Independent verification is not yet claimed.
⚖️ What SERA Does — and Does Not — Claim
SERA does not claim that conventional selections, ranges, patches, or editing tools should disappear.
It does not replace collaborative merge systems.
It does not guarantee that every structural target can always be resolved.
It does not claim universal linguistic correctness.
It does not claim production readiness by default.
Its current question is narrower:
Can document mutation be governed by explicit structural resolution and commit-time admission instead of allowing a proposal artifact, supplied coordinates, or raw machine output to become the final mutation authority?
The bounded principle is:
uncertainty or invalidated authority -> explicit non-mutation
not:
uncertainty -> forced edit
🌐 Explore SERA
Experience the current Structural Keyboard reference surface directly in the browser, or explore the repository for the implementation, architecture documentation, conformance specifications, audit material, verification guidance, schemas, evidence structures, and supporting documentation.
🌐 Launch the SERA Structural Keyboard Live Demo on GitHub pages
🔗 SERA — Open Reference Implementation on GitHub
🌌 The Larger Question
For years, document editing has largely asked:
What text was selected?
AI editing adds another question:
What change did the model propose?
SERA adds a third:
What does the current document structure actually permit this proposal to change?
That distinction may become increasingly important as editing moves from direct human manipulation toward AI agents and automated systems capable of modifying documents on our behalf.
The deeper principle is simple:
Anyone may propose. Structure resolves. Admission permits. Evidence records.
And for the Structural Keyboard reference surface:
Edit at the level you think.
✍️ Authorship & Disclaimer
Created by the authors of the Shunyaya Framework.
SERA is a bounded structural edit-resolution and admission reference architecture, implementation, and research program.
It is not intended for safety-critical or production-critical deployment without independent validation, domain-specific testing, appropriate authorization controls, and suitable host-system safeguards.
OMP
Comments
Post a Comment