Why Can’t I Directly Rewrite My Own Page? Lessons From the /translation/ Redesign on Immutable Source and Replacement Successor

While reorganizing the /translation/ page for Go Learning & Documentation v2 recently, I ran into a problem that initially seemed very strange.

This page is not an official document from the upstream go.dev.

It has always been the project’s own page.

I wrote the content myself.

Now I want to reorganize it:

• Adjust the paragraph order;
• Reorganize the existing explanations;
• Merge some older content;
• Add a new project introduction;
• Make the entire page better fit the project’s current positioning, which has expanded from just a Go Tour to covering Learn, Docs, and more.

From the perspective of regular website maintenance, this is a very simple task.

Open:

data/site-shell/translation.html

data/site-shell/translation.html

and just edit the text directly.

But once I actually entered the formal workflow, I discovered:

Although this file is mine, it can no longer be treated as ordinary HTML to be modified freely.

Because it has become:

A canonical source consumed by the formal language workflow.

The difference between these two states is massive.

Ultimately, this problem cannot be solved by:

“Since it’s my own website, I’ll just change it directly.”

Instead, it requires specifically establishing:

consumed-source replacement successor authority.

This article organizes why this happens, and why “appending new content” and “rewriting already consumed text” are actually two completely different lifecycle operations.

Why a file transitions from a “regular file” to a formal source authority

Initially, translation.html was just a source file.

Modifying it at this point carried no special meaning.

For example:

Old text
→ Edit
→ New text

Old text
→ Edit
→ New text

As long as the page displayed correctly, it was fine.

But once it enters the formal translation lifecycle, things change.

It progressively participates in:

• source extraction;
• semantic slots;
• unified corpus;
• glossary review;
• Generation;
• structured output;
• validation;
• package closure;
• Integrated Surface Review;
• Activation.

After reaching this stage, a series of formal evidence will be bound to:

the exact source bytes at that time.

This means an accepted target does not exist in a vacuum.

What it actually proves is:

For a specific source, under a specific language authority, this target was once formally generated, validated, and accepted.

So if the source is later modified in place:

source A
→ directly overwritten at the original path to source B

source A
→ directly overwritten at the original path to source B

the historical evidence immediately raises a question:

Were those past PASSes actually reviewing A, or B?

The answer can only be A.

But the original A on disk no longer exists.

immutable does not mean “content can never be updated”

It is easy to form a misunderstanding here.

Since the source is immutable, does that mean:

the page can never be modified after publication?

Of course not.

What immutable truly expresses here is:

A historical source that has already been consumed by formal evidence cannot be secretly rewritten into different content, pretending that the old evidence still corresponds to the new content.

This is “history cannot be rewritten.”

It is not “the product cannot continue to evolve.”

The correct way to evolve should be:

Old source authority
→ Retained

New source successor
→ Establish new formal authority

Old source authority
→ Retained

New source successor
→ Establish new formal authority

Then the new authority proceeds through its required subsequent lifecycle.

This allows us to achieve both:

Historical evidence remains trustworthy.

and:

The current product can continue to change.

The problem with /translation/ is precisely that it is not simply “adding two paragraphs of text”

What actually stopped me this time is that the modifications I wanted to make went beyond an append.

Assume the old page was:

Part 1: Project introduction
Part 2: Tour instructions
Part 3: How to participate

Part 1: Project introduction
Part 2: Tour instructions
Part 3: How to participate

If I now just wanted to add at the end:

Part 4: Learn / Docs

Part 4: Learn / Docs

This would be a relatively easy change to describe:

All old content is retained, and new content is simply added after it.

But what I really want to do this time is closer to:

Rewrite the project introduction
→ Merge the old Tour instructions
→ Move Learn / Docs to the front
→ Adjust the participation instructions
→ Delete outdated descriptions
→ Add a new project scope explanation

Rewrite the project introduction
→ Merge the old Tour instructions
→ Move Learn / Docs to the front
→ Adjust the participation instructions
→ Delete outdated descriptions
→ Add a new project scope explanation

This is not:

append.

But rather:

replacement / reorganization.

That is, the old text itself needs to be reorganized internally.

Why the project already has structured-source-adopt, but still cannot solve this directly

The project had previously established a structured source successor path:

site-content structured-source-adopt

site-content structured-source-adopt

It does allow:

Adding new canonical prose on top of existing structured source.

But this capability is intentionally restricted.

The current contract requires:

All old semantic slots remain completely unchanged.

And the newly added text can only be placed:

After all existing semantic slots.

In other words, it can legitimately express:

Old text A
Old text B
Old text C
New text D

Old text A
Old text B
Old text C
New text D

but it cannot express:

Old text A
→ Rewrite

Old text B
→ Delete

Old text C
→ Move to the front

New text D
→ Insert in the middle

Old text A
→ Rewrite

Old text B
→ Delete

Old text C
→ Move to the front

New text D
→ Insert in the middle

This is not due to a lack of tool capability.

Rather, its authority was never intended to do this in the first place.

The value of an append successor lies in “old content can continue to be inherited precisely”

Why restrict append so strictly?

Because it offers a major advantage:

The language results of the old content can be carried precisely.

Assume the old source has 10 semantic slots.

They have already completed:

slot 1 → accepted target 1
slot 2 → accepted target 2
...
slot 10 → accepted target 10

slot 1 → accepted target 1
slot 2 → accepted target 2
...
slot 10 → accepted target 10

Now, just append two new slots:

slot 11
slot 12

slot 11
slot 12

As long as we can prove that:

• The old source bytes remain unchanged;
• The old coordinates remain unchanged;
• The old semantic roles remain unchanged;
• The old protected representation remains unchanged;
• The old targets remain valid;

then we can safely say:

1–10 are an exact carry.

What actually needs to enter Generation is only:

11–12.

This is the greatest value of an append successor.

Once the text is reorganized, old coordinates and semantic boundaries may all change

But replacement is different.

For example, the old text contains:

Paragraph A
Paragraph B
Paragraph C

Paragraph A
Paragraph B
Paragraph C

The new text becomes:

Rewrite of Paragraph C
New Paragraph D
Partial content from Paragraph A

Rewrite of Paragraph C
New Paragraph D
Partial content from Paragraph A

In this case, you cannot simply say:

A seems to still be there, so carry it.

Because what the formal workflow truly needs to prove is:

Whether it is the same semantic input.

Not just:

The Chinese meaning looks about the same.

Or:

Certain strings appear repeatedly.

Especially since structured source also has:

• coordinate;
• slot identity;
• role/context;
• protected structure;
• source hash;

These formal boundaries.

If the text is reorganized, relying on string similarity to guess:

This new slot is probably that old one.

carries significant risk.

“Same meaning” cannot serve as machine carry authority

For example, the old source has a sentence:

Learn about Go.

After the new source is reorganized, it still appears:

Learn about Go.

To the naked eye, they look completely identical.

But it might have:

• Appeared in another section;
• Taken on an explanation under a different heading;
• Corresponded to a different link;
• Had its surrounding context change.

If the workflow automatically inherits the old target just because the source string is the same, it might move:

A valid translation from the old context

incorrectly into:

the new context.

So formal carry cannot rely on:

The text looking the same.

It must rely on:

Provable source identity and semantic positional relationships.

This happens to form a contrast with the previous books.yaml 10→12 issue

I previously wrote about a books.yaml semantic input expansion.

In that case:

The original file bytes did not change.

But the parser went from previously recognizing 10 formal language inputs to now recognizing 12.

So the old Generation could no longer masquerade as the current complete result.

This /translation/ case is exactly the opposite direction.

It is not:

bytes unchanged, but formal semantic inputs increased.

But rather:

I actively want to change the canonical source body itself.

These two situations jointly illustrate:

Determining whether an old translation can still be used cannot rely solely on whether a file path is still called the same name.

What actually needs to be compared is:

What the language model was originally asked to translate.

and:

What it is formally asked to process now.

Whether it is still the same task.

Why you can’t secretly add a paragraph of Chinese in the renderer

After discovering that the source authority does not allow direct modification, there is another very tempting shortcut:

Then I won’t change the language source.

Can’t I just have the renderer output an extra paragraph of Chinese on the /translation/ page?

From the perspective of page effect, this can indeed be done.

For example, the renderer directly outputs:

Original formal target
+
A new paragraph of Chinese project description

Original formal target
+
A new paragraph of Chinese project description

The browser looks completely normal.

But doing this creates an even more serious problem:

This Chinese text has never entered the formal language authority.

It has not gone through:

• corpus;
• glossary;
• Generation;
• validation;
• Independent QC;
• package closure;
• Surface language review.

That is to say:

The renderer begins secretly assuming language generation responsibilities.

This bypasses the entire formal workflow.

A renderer should render formal content, not create formal language content

This boundary later felt very important to me.

The Renderer can be responsible for:

• layout;
• HTML composition;
• route presentation;
• CSS;
• shared chrome;
• canonical;
• sitemap;
• runtime behavior.

But it should not be responsible for:

Using engineering code to add a paragraph of Chinese text that has never been through the formal language workflow.

Otherwise, when looking at a sentence in Chinese on the page later, it will be impossible to answer:

Which canonical source does it come from?

Which Generation?

Which Reviewer?

Which target SHA?

Which closure?

Or even:

What should other locales do?

So:

renderer injection cannot become a bypass for source replacement.

Nor can you skip language authority just because “this is a native Chinese page”

There is also a very natural thought here:

/translation/ was originally the project’s own page.

I’ll just write Chinese directly, why do I still need Generation?

The problem is that this project is not:

A zh-CN only website.

It is:

A formal multi-locale content system.

If the canonical source model allowed a specific locale to get special text directly in the renderer, then other languages would later face:

zh-CN: Engineering code writes Chinese directly
fr-FR: Goes through Generation
de-DE: Goes through Generation
ja-JP: Uses another set?

zh-CN: Engineering code writes Chinese directly
fr-FR: Goes through Generation
de-DE: Goes through Generation
ja-JP: Uses another set?

The language authority would quickly diverge.

So even if this page is owned by the project, it should still continue to maintain:

canonical source → locale Generation / carry → validation → review.

Instead of hardcoding target language text manually by locale.

source ownership and source lifecycle are two different things

This is also the easiest point to confuse this time.

“This is my own page” resolves:

Who has the right to decide what the source should say.

But the formal lifecycle resolves:

Whether existing language results can still be trusted after the source changes.

The two are completely different.

I can certainly decide:

What the new version of /translation/ should look like.

But once the new canonical source is decided, the following still need to be answered:

What is the relationship between the new source and the old source?

Which old language results can be carried precisely?

Which must be regenerated?

Has the glossary corpus changed?

Does the old Review still cover the current corpus?

Does the new target require new independent QC?

These questions do not disappear just because I am the source owner.

Why “directly modifying the original file” destroys recoverability

Besides auditing, in-place modification has another very practical issue:

recovery.

Assume the old text is directly overwritten.

Then the new workflow fails halfway through.

For example:

New corpus established
→ Glossary review not yet completed
→ Generation not yet executed

New corpus established
→ Glossary review not yet completed
→ Generation not yet executed

At this point, in the current repository:

The old source is gone.

But the new source:

Has not yet completed its language lifecycle.

Then the system can hardly answer accurately:

Which source should current Production continue to trust?

If the old source authority itself remains immutable, and the new replacement successor is merely:

An incomplete successor,

recovery is much simpler:

current accepted authority
→ Continue keeping the old version

new successor
→ pending

current accepted authority
→ Continue keeping the old version

new successor
→ pending

Only after the new chain is truly completed do we switch the current authority.

This is actually very similar to database migration

Later, I felt this could be understood as a kind of content migration.

You should not do:

UPDATE current_content
SET body = new_body

UPDATE current_content
SET body = new_body

and then hope all previous evidence automatically remains valid.

It is more reasonable to:

Old version
→ immutable

New version
→ successor

Complete validation / review / closure
→ Then formally switch current

Old version
→ immutable

New version
→ successor

Complete validation / review / closure
→ Then formally switch current

This way, every historical state has traceability.

If it fails midway, you also know:

Which state is still the last trusted version.

source adoption itself is not language acceptance either

Even if the new source successor has been successfully established, you cannot immediately say:

The page update is complete.

What Source adoption truly proves is:

The new canonical source authority legally exists.

It does not prove:

The target has been generated.

Still less does it prove:

The target quality has passed.

So after a formal source successor, it may still need:

source successor
→ corpus successor
→ glossary refresh / review
→ Generation
→ validation
→ Independent QC
→ A-only finalization
→ package closure
→ Integrated Surface
→ Activation

source successor
→ corpus successor
→ glossary refresh / review
→ Generation
→ validation
→ Independent QC
→ A-only finalization
→ package closure
→ Integrated Surface
→ Activation

Which specific stages need to be re-executed will be determined by the source delta and formal currentness.

But source adoption itself must never skip these stages.

Why the corpus must also advance with the source successor

One of the roles of the Unified corpus is to tell the glossary workflow:

What language contexts actually exist in the current formal content.

If the /translation/ source has been heavily rewritten, but the corpus still retains:

Old version contributor contexts,

then what the glossary review is actually reviewing is still:

The linguistic world of the past.

At this point, even if the glossary file itself hasn’t changed a single word, you cannot automatically say:

The current Review still covers the new source.

Therefore, after a replacement successor, you typically still need:

a corpus successor.

Then re-evaluate:

Whether the new corpus introduces terminology impacts.

Glossary unchanged does not mean Review can definitely be reused directly

This is also an easy point to misunderstand.

Assume the new /translation/ only reorganizes the project introduction and introduces no new terms.

Ultimately, glossary.yaml might really not need a single word changed.

But it still needs to be proven that:

The current Unified Review covers the new corpus identity.

Because what Independent Glossary Review audits is not just YAML bytes.

It also means:

Whether the current glossary is sufficient to cover the current formal corpus.

So:

glossary bytes unchanged

and:

glossary review current

are not the same concept.

Why replacement successor is more costly than append successor

Now it is easy to understand why the costs of these two differ so much.

Append successor

The old text remains exact.

So you can:

Carry extensively.

Primarily handling:

Newly added slots.

Replacement successor

The old text allows:

• Rewriting;
• Deletion;
• Reordering;
• Merging;
• Splitting.

Thus, the system must re-evaluate:

Which old semantic results still have a legitimate inheritance relationship.

Parts that cannot be proven cannot be carried.

Therefore, replacement successor is inherently more expensive than append:

More expensive.

But this is a cost of correctness.

It is not a tool design flaw.

If the actual need is just to append, do not upgrade to replacement

Conversely, this also means:

Not all source updates should go through the heaviest replacement lifecycle.

If the real need is just:

Adding a new independent section at the end of the text.

And all old semantic slots can be proven byte-for-byte unchanged.

Then append successor is clearly more reasonable.

Because it maximally preserves:

Old language results that have already been formally reviewed.

So the correct principle is not:

Replacement is more advanced, so use replacement for everything.

But rather:

The mutation type must match the actual source change type.

append and replace should be distinguished at the source authority layer

You shouldn’t wait until the Generation stage to discover:

The old content was actually reordered.

Because by then, the formal input identity has already changed.

It is more reasonable to classify at the source layer first.

If the change satisfies:

Old text is completely preserved, only adding suffix semantic content.

Then enter:

append successor.

If the change requires:

Deleting, rewriting, reordering, or reorganizing already consumed text.

Then enter:

replacement successor.

This is a source authority decision.

It is not decided by Generation itself.

Why you can’t let Generation “casually reorganize” on the side

There is also another seemingly labor-saving idea:

Give the old target to Generation, and let it directly rewrite the Chinese version based on the new requirements.

This actually mixes two different tasks together.

The first task is:

What the canonical source should become.

The second task is:

How the current locale should translate this canonical source.

Generation should only be responsible for the second.

Otherwise, it will start deciding:

• Which part of the source should be deleted;
• Which content should be added;
• How the project structure should be rewritten;

This is no longer translation Generation.

It is:

source authoring.

The roles become confused.

canonical source must first be established independently

So the correct order should be:

First decide the new canonical source.

Let the new source itself be valid outside of the target language.

Then ask:

What target should be generated for zh-CN?

What target should be generated for other locales in the future?

This ensures that all languages still share:

The same source authority.

Instead of each locale developing its own increasingly different project description.

Why historical evidence must continue pointing to the old source

Assume the old /translation/ has already gone through:

• Generation;
• validation;
• package closure;
• Surface;
• activation.

This evidence actually happened.

After the new replacement successor is established, these historical records should not be modified to:

They were actually reviewing the new source.

Because that would be false.

The correct state should be:

Old source A
→ Old Generation
→ Old accepted target
→ Old closure
→ Old Surface

New source B
→ New successor lifecycle

Old source A
→ Old Generation
→ Old accepted target
→ Old closure
→ Old Surface

New source B
→ New successor lifecycle

If B ultimately succeeds:

current authority switches to B.

But A’s historical chain remains intact.

This also explains why replacement cannot overwrite old receipts

A formal receipt should be:

content-addressed / immutable.

If the new proposal fails, you cannot go back and change the old receipt to:

new content.

Otherwise, the same receipt identity would represent different facts at different times.

Then historical references lose their meaning.

So:

New source, new proposal, new receipt.

Old artifacts are retained.

This is the foundation of recoverability.

When a source draft has not yet been consumed, the situation can be different

There is another very important boundary here.

Assume a new structured source proposal was just created.

But it has:

• Not yet entered the corpus;
• Not been referenced by any immutable corpus successor;
• Not entered Generation;
• No accepted language result.

At this point, you discover:

There is a typo in the new text.

Then it still counts as:

A source draft correction that has not yet been consumed.

This is different from a replacement after it has already been consumed by the formal language workflow.

The former can establish a new proposal/body/receipt under strict CAS and replace the current source pointer.

The latter can no longer use this lightweight correction path.

Because once it has been consumed:

Historical dependencies exist.

“Whether it has been consumed” is more important than “whether it is live”

This boundary is also very interesting.

Often we intuitively think:

As long as it’s not in Production yet, just change it freely.

Not necessarily.

Even if the page is not officially live yet, as long as the new source has already been:

• corpus successor;
• Glossary Review;
• Generation;
• QC;

formally consumed, it has already formed historical dependencies.

Modifying the source in place at this point will also break the lineage.

So the truly critical question is not:

Is it live?

But rather:

Has formal immutable evidence been generated that references this source?

fail-closed here means “better to temporarily not be able to change it than to guess”

The /translation/ redesign ultimately stopping this time actually aligns well with the fail-closed principle the project has always adhered to.

At that time, without a formal replacement authority, there were two options.

The first option:

Directly modify the file and keep pushing forward.

The second option:

Stop, and first establish an authority capable of legitimately expressing replacement.

The second is obviously slower.

But it avoids many problems that would be harder to explain later.

Because once you change it directly:

Exactly which old evidence is still credible?

It quickly becomes blurry.

So:

When it is impossible to prove how old language results map to the new source, do not guess the carry.

Similarly:

When the current authority cannot legitimately express text replacement, do not modify it via a bypass.

This is the practical meaning of fail-closed in the content lifecycle.

This time I increasingly feel that “content” itself needs a migration contract

When talking about migration previously, it was easy to think of:

• database;
• schema;
• API;
• filesystem.

But working on this until now, I found that formal multilingual content also needs a migration contract.

Especially when it already has:

• identity;
• review evidence;
• dependency;
• currentness;
• historical lineage;

afterward, it is essentially a kind of:

versioned data.

Since it is versioned data, it is not suitable for:

direct overwriting.

Instead, it should:

predecessor → successor.

What’s truly hard about content workflows isn’t “generating new text”

It is actually quite easy for the model to regenerate a version in Chinese.

What is truly difficult is answering:

Why does it need to be regenerated this time?

Which old results can be kept?

Which cannot be kept?

Which predecessor does the new result inherit from?

Which source does the new candidate correspond to?

Is old A still valid?

When can the new target replace the current target?

These questions are not:

“How well did the model translate”

that can solve them.

They belong to:

content state management.

/translation/ this time let me distinguish three completely different changes

Now I am more inclined to divide structured source changes into three categories.

Category 1: semantic inputs expansion

Such as the previous books.yaml 10→12.

The characteristic is:

The raw source might not have changed, but the current parser recognizes new formal language inputs.

Needs to handle:

semantic input expansion.

Category 2: append-only source successor

The characteristic is:

Old text and old semantic slots all remain exact, only adding new canonical content at allowed positions.

The advantage is:

Old accepted slots can be carried precisely.

Category 3: consumed-source replacement successor

The characteristic is:

Text that has already been consumed by the formal workflow needs to be rewritten, deleted, reordered, or reorganized.

In this case, you cannot pretend the old slot identity still holds intact.

You must enter:

formal replacement lifecycle.

These three issues all appear to be called:

“The content changed.”

But the machine authority is completely different.

You cannot use a single generic “content update” button to handle all situations

If you cram all three types of changes above into a single command:

update-content

update-content

and then internally automatically guess:

• carry;
• replace;
• append;
• retranslate;

it will be very dangerous.

Because the machine needs to be based on:

precise proof

not:

heuristic.

So it is better for different mutations to have different authorities.

This way, when it fails, you also know:

Exactly which layer failed to prove valid.

replacement successor should ultimately still return to the shared TranslationUnit lifecycle

Another very important design point is:

replacement should not establish a second translation state machine.

Source replacement resolves:

How the new canonical source legally supersedes the old source.

Once the new source authority is established, the actual translation part should still try to return to the existing shared lifecycle:

Generation
→ import / restore
→ validation
→ Candidate Snapshot
→ Independent QC
→ revision / re-QC
→ A-only finalization
→ package closure

Generation
→ import / restore
→ validation
→ Candidate Snapshot
→ Independent QC
→ revision / re-QC
→ A-only finalization
→ package closure

This way, replacement is just:

The authority bridge for the new predecessor/current source.

Instead of inventing:

ReplacementTranslationStatus, ReplacementQC, ReplacementFinalization.

Otherwise, there will be more and more state machines.

Integrated Surface still cannot be skipped

Even if the replacement target ultimately receives an A again, it does not mean:

The page is ready to go live directly.

Because /translation/ itself is still part of the Site shell.

After the text is reorganized, it might affect:

• Page links;
• navigation;
• local coverage instructions;
• project entry points;
• relationship with the Homepage;
• display of other packages.

So ultimately it still needs:

Integrated Surface Review.

It is responsible for re-checking:

Whether the new page still holds up when placed back into the complete site.

Source replacement PASS also does not equal Production ready

Therefore, the entire proof chain must continue to be strictly layered.

Source replacement authority PASS can only prove:

The new canonical source is legally established.

Corpus successor PASS can only prove:

The current corpus has been formally updated.

Glossary Review PASS can only prove:

The current glossary has received independent language review for the current corpus.

TranslationUnit A can only prove:

The language quality of the current target has passed.

Package Closure can only prove:

The current content package is complete.

Surface PASS can only prove:

Site integration passed.

Activation, Preview, and Production still each have their own scope of proof.

This actually connects back to the previous wrong renderer article:

A PASS can never replace the next layer that it did not check.

Why this entire process looks much more troublesome than “directly editing HTML”

Because “directly editing HTML” only solves:

Whether the page looks right now.

The formal lifecycle also needs to solve:

Whether history can be explained.

Whether it can be recovered after failure.

Whether other locales can reuse the same source.

Whether old accepted results can be safely inherited.

Whether the language impact of the new source has been fully reviewed.

Whether the current authority can be determined.

These are not questions that regular static site editing needs to answer.

Once the project enters:

multi-locale + independent Reviewer + immutable evidence + incremental update,

complexity naturally rises.

But this complexity buys “not having to overthrow all old results”

Its other side is actually:

Precisely because the predecessor / successor relationship is strictly preserved, safe incremental updates are possible.

Without these identities and authorities, the simplest approach would of course be:

Page has changes
→ Re-translate the entire locale
→ Re-Reviewer everything
→ Re-Surface everything

Page has changes
→ Re-translate the entire locale
→ Re-Reviewer everything
→ Re-Surface everything

That would be very simple to implement.

But the cost would also be very high.

What we really want to achieve now is:

Only the parts truly affected by the source replacement re-enter the language lifecycle.

Unaffected packages, Pages, and historical results continue to carry.

So the goal of strict source authority is not just:

adding restrictions.

It is also:

allowing safe reuse.

append successor and replacement successor are actually answering the same question

They jointly answer:

How much of the old results can actually be reused?

The answer for append successor is usually:

Almost all old slots can be exact carried, only generating the newly added parts.

The answer for replacement successor is more cautious:

Only carry the parts that can be formally proven to still have the same source/semantic identity; the rest enter the new language lifecycle.

The difference is not:

which tool is more powerful.

But rather:

the nature of the source mutation is different.

The most worthwhile judgment criterion to keep from this time

When encountering similar content redesigns in the future, I feel the first question shouldn’t be:

Can I directly edit this file?

But rather should first ask:

Has this source already been consumed by formal evidence?

If not:

It still belongs to regular source authoring or restricted draft correction.

If already consumed:

Then ask:

Is this change an append, or a replacement?

If the old text can all be kept exact, only adding new content:

append successor.

If it requires rewriting, deleting, reordering, or reorganizing the old text:

replacement successor.

Once this judgment is made correctly, the subsequent lifecycle won’t go wrong.

A few principles I now agree with more

After this /translation/ redesign, I feel the rules for source evolution can be condensed into a few points.

First:

source ownership does not mean you can bypass the source lifecycle; once your own page is consumed by formal language evidence, it must equally maintain historical traceability.

Second:

The meaning of immutable is not “can never be changed”, but “old facts cannot be overwritten in place by new facts”.

Third:

Adding new content only after old semantic slots belongs to append successor; rewriting, deleting, or reordering consumed text belongs to replacement.

Fourth:

The prerequisite for append to safely carry old results is that the old source, slot identity, coordinate, role, and protection can all be precisely proven to remain unchanged.

Fifth:

You cannot let the machine guess which new slot an old target should carry to just because the strings are identical or the semantics are similar.

Sixth:

A renderer can only render formal language content; it cannot secretly inject target language text that has not been through corpus, Generation, and Review.

Seventh:

source adoption only establishes canonical source authority; it does not equal language acceptance, much less Production ready.

Eighth:

After a new source successor enters the current corpus, it must be re-evaluated whether the Unified Glossary Review is still current.

Ninth:

A source draft not yet consumed by the formal workflow can use a restricted correction path; once it has been consumed by corpus, Generation, or other immutable evidence, it can no longer pretend to be just a regular draft.

Tenth:

replacement should resolve the source authority change, but subsequent language processing should still return to the shared TranslationUnit lifecycle, without establishing another QC state machine.

Ultimately, I feel the most memorable sentence from this time is:

The page belongs to me, which does not mean its history can be rewritten by me.

When a piece of content is still just a regular file:

Editing it is just editing a file.

But once it has been translated, reviewed, sealed, and entered the formal site authority:

Modifying it is no longer just “changing a few paragraphs of HTML”.

But rather doing a:

content version migration.

At this point, what truly needs to be protected is not just the text displayed on the page today.

It also includes:

The history that was proven true yesterday.