【宋词】《六州歌头》 张孝祥：长怀望断，关塞莽然平。征尘暗，霜风劲，悄边声。黯销凝。追想当年事，殆天数，非人力，洙泗上，弦歌地，亦膻腥。隔水毡乡，

永夜

没有不值得去解决的问题，也没有不值得去学习的技术！

Protection Mechanisms Can Protect the Wrong Things: Why a Single Documentation Block Revisions for an Entire Page

Protection Mechanisms Can Protect the Wrong Things: Why a Single Documentation Block Revisions for an Entire Page

作者：

永夜

在

Views: 0

In the translation workflow for Go Learning & Documentation v2, I have always placed great importance on one thing:

The model must not arbitrarily modify code, URLs, identifiers, link bindings, and other machine-semantic content.

Therefore, before a formal TranslationUnit is handed over to Generation, the raw Markdown or HTML is not fed directly to the model.

There is an intermediate layer:

protected representation.

It replaces content that should not be modified by the language model with protected tokens, leaving only the natural language parts that are truly allowed to be translated or revised.

This mechanism solves a very important problem.

For example, if the source contains:

Plaintext
http.Client

Or:

Plaintext
https://go.dev/doc/

Or a Markdown link, an HTML attribute, or a Go identifier.

The model should not change these just because it feels Chinese reads more naturally.

Therefore, the safest approach is:

Simply do not give the model the ability to edit them.

But later I encountered the exact opposite problem.

On one occasion, an independent Reviewer had explicitly pointed out a language issue on a Page that required revision.

The Generation Bundle was also set up normally.

But when it was actually time to execute the exact revision, I discovered:

The natural language that needed to be changed was protected by the current representation as opaque protected content.

One intuitive example is something like:

Plaintext
Documentation

Such an ordinary visible label.

The Reviewer can see it.

It is also easy for a human to judge:

This is natural language on the page.

But in the protected baseline that Generation receives, it has already become an uneditable token.

At this point, the problem becomes very interesting:

The translation knows how it should be changed.

The Reviewer has also formally authorized the change.

But the machine representation simply does not allow Generation to touch it.

Ultimately, this can even result in:

Plaintext
formal revision batch
→ Generation cannot legally express the finding
→ 0 output
→ FAILED

This is not the model failing to translate.

It is also not the Reviewer finding being wrong.

It is that:

The current representation contract lacks the capability to express a language change that is otherwise legitimate.

This article is dedicated to sorting out this problem.

Why the translation workflow needs protected representation

Let’s start with the most basic question.

Why not just hand over the entire Page source to the model?

Because a documentation page usually contains more than just natural language.

It may also contain:

  • Go identifier;
  • API name;
  • URL;
  • Markdown link destination;
  • HTML tag;
  • attribute;
  • code block;
  • directive;
  • placeholder;
  • template syntax;
  • technical literal.

Some of this content absolutely must not be translated.

For example:

Plaintext
json.Marshal

Cannot be changed into Chinese.

URL:

Plaintext
https://go.dev/doc/

Cannot be arbitrarily respelled by the model.

Markdown link:

Plaintext
[Documentation](/doc/)

Usually needs to distinguish:

Documentation is visible language.

While:

/doc/ is a machine binding.

So what the formal protector essentially does is:

Separate “language” from “machine semantics”.

What an ideal protected input should look like

For example, the source text:

Plaintext
Read the Documentation for more details.

If Documentation is just ordinary visible text, ideally Generation should be able to see and modify it.

And if the page contains:

Plaintext
http.Client

The protector might turn it into something like:

Plaintext
Read the Documentation for more details about ⟦P17⟧.

The model can edit:

Ordinary English prose.

But cannot edit:

Plaintext
⟦P17⟧

Upon restore:

Plaintext
⟦P17⟧

It is restored back to:

Plaintext
http.Client

This allows natural language translation while ensuring that technical identity is not broken.

The problem occurs when “natural language is misclassified as technical content”

The truly troublesome case is:

The protector classification is wrong.

For example, a heading navigation label on a page is originally ordinary text truly visible to the user.

But when the source tokenizer makes its judgment, because a nearby word might be recognized as a symbol lead, the subsequent ordinary label is incorrectly classified as an opaque atom.

So what was originally supposed to be:

Plaintext
Editable natural language: Documentation

Ultimately becomes:

Plaintext
Uneditable protected atom: ⟦P42⟧

At this point, the TranslationUnit is still completely valid from a machine perspective.

The token is not corrupted.

The restore might also be completely successful.

But it hides a capability issue:

The model has lost the ability to modify this natural language.

“Protecting more” is not necessarily safer

At first, it is easy to instinctively think:

It is better to over-protect than to let the model mistakenly alter technical content.

For many systems, this is indeed a reasonable conservative strategy.

But in a formal translation workflow, there is another side.

If ordinary natural language is incorrectly protected, it leads to:

Legitimate language revisions being unable to occur.

So the correct goal of the protector is not:

To protect as much content as possible.

But rather:

To precisely protect only the content that the language model is truly not allowed to modify.

Under-protecting carries risks.

Over-protecting also carries risks.

Why the Reviewer can still spot the problem

An interesting layered discrepancy appears here.

What Generation receives is:

protected input.

While the Reviewer reviews:

restored candidate.

That is, the complete target language content that the final reader will actually see.

So the Reviewer can totally see:

A certain label is translated unnaturally.

Then normally issue a B finding.

For example, the Reviewer’s judgment might be something like:

The current visible navigation label should use a more natural Chinese expression.

There is absolutely no problem with this finding itself.

From the perspective of the final page semantics, it indeed should be fixed.

The real problem is not exposed until the revision export or Generation phase:

The text that the Reviewer authorized to change is completely uneditable in the Generation representation.

This is not an ordinary translation revision failure

If Generation simply changed a sentence incorrectly, the fix is straightforward:

Plaintext
Reviewer issues B
→ exact revision
→ validation
→ successor re-QC

But a representation capability failure is different.

Because even if Generation fully understands the Reviewer’s intent, it has no legitimate way to output the correct result.

Assume the protected baseline is:

Plaintext
For more information, please refer to ⟦P42⟧.

And ⟦P42⟧ actually corresponds to:

Plaintext
Documentation

If the Reviewer requests adjusting this label, Generation has three options.

The first option:

Modify the ⟦P42⟧ token.

Not allowed.

The second option:

Delete the token, then handwrite the Chinese.

Still not allowed.

The third option:

Keep the token untouched.

Then the Reviewer finding cannot be closed.

Therefore:

There is no legitimate ordinary revision output.

This is also why “letting the model directly modify tokens” is absolutely not a solution

The most dangerous fix might be:

Since the model knows ⟦P42⟧ is Documentation, just allow it to change it.

This completely destroys the purpose of protected representation.

Because next time, the same capability could be used to modify:

  • Go identifier;
  • URL;
  • code literal;
  • link destination;
  • template syntax.

The token is inherently a machine boundary.

Generation should not possess:

The power to decide which token can be cracked.

This kind of authority.

Otherwise the protector degenerates from:

machine-enforced safety boundary

Into:

hoping the model behaves itself.

This is clearly not reliable enough.

Nor can you just re-Protect the candidate

Another seemingly convenient approach is:

Since the old protected baseline is unusable, why not take the candidate reviewed by the Reviewer and re-protect it with today’s protector?

This method also has major issues.

Because the candidate is:

target language.

While the formal token mapping should be determined by:

canonical source-owned representation

If you reverse-Protect from the translation, the machine will likely have to guess:

Which atom in the source does a certain word in the target correspond to?

When a technical literal appears multiple times in the target, this ambiguity becomes even more pronounced.

Therefore, the formal rules always emphasize:

Do not guess token mapping from the target.

The representation mapping must be determined by the source authority and the historical formal representation.

“Today’s protector is more correct” also cannot rewrite yesterday’s history

Assume the tokenizer is later fixed.

It can now correctly determine that:

Plaintext
Documentation

Belongs to:

Ordinary visible natural language.

The new protected input also becomes reasonable.

But this does not mean we can go back and modify old batches.

Because the old batch’s:

  • manifest;
  • input SHA;
  • Unit ID;
  • raw response;
  • candidate;
  • validation;
  • QC evidence;

Have already become history.

If the old input is replaced in-place with the new representation, there will be:

The same batch identity corresponding to different formal inputs at different times.

This directly breaks provenance.

So the old failure must be kept as is.

A 0 output failure should also become history, not be “fixed away”

I feel this point is particularly important.

At the time, there existed a formal failure state:

Plaintext
Generation batch established
→ representation cannot express the finding
→ 0 output
→ no import
→ no process

The easiest impulse is:

Since we now know the engineering reason, just re-export this batch and erase the old failure.

But this should not be done.

The correct approach should be:

Plaintext
Old failed batch
→ immutable preserved

New representation authority
→ successor

New revision batch
→ continue processing the same finding

Because the old failure itself is also valuable evidence.

It truly records that:

The formal representation at the time lacked the capability to complete this task.

Fixing the protector and fixing the TranslationUnit are not the same thing

There is another easily confusing aspect to this case.

Fixing the tokenizer in engineering, for example:

Heading navigation labels are no longer misidentified as opaque atoms.

Only proves that:

Future current representations can be generated correctly.

But the existing TranslationUnit identity may depend on the old protected input.

If the new protector output changes, then:

Plaintext
old protected input
≠
current protected input

The Unit identity may also change accordingly.

So you cannot simply say:

The parser is fixed, just rerun it now.

You also need to resolve:

What is the relationship between the old Unit and the current Unit?

This is why the representation successor authority exists.

The physical source hasn’t changed, but the formal Unit may still change

This actually echoes the article books.yaml a bit.

Ordinary intuition would suggest:

The Page source hasn’t changed a single word, so it’s still the same TranslationUnit.

But the formal Unit identity does not necessarily depend only on:

physical source bytes.

It may also depend on:

protected representation.

So it can happen that:

Plaintext
physical Page source: completely unchanged
current parser: fixed classification
protected input: changed
formal Unit ID: changed

This is not source content replacement.

It is:

representation replacement.

Source replacement and representation replacement must be separated

These two terms look similar, but the problems are completely different.

Source replacement

The canonical source itself changes.

For example:

/translation/ body text is reorganized.

In this case, you need to handle:

new source authority.

Representation replacement

The canonical source bytes have not changed.

But the parser / protector’s formal representation of the same source has changed.

For example:

What was previously treated as an opaque atom for an ordinary visible label is now correctly classified as natural language.

What needs to be handled here is:

old representation → current representation.

You cannot conflate the two situations into:

“The file changed.”

Because the first one actually changed the source.

The second one did not.

The representation successor’s task is not to generate a new translation

This point is also crucial.

When establishing the representation successor authority, the system is not doing:

Translating for Generation.

But rather proving:

The old formal Unit and the current formal Unit are the legal predecessor / successor of the same physical Page under two formal representations.

It needs to verify many machine facts, such as:

  • Same package;
  • Same physical path;
  • Same source bytes;
  • Same route;
  • Same registry index;
  • Same dependency identity;
  • The old representation truly exists;
  • The current representation can be rebuilt by the current parser.

Only when all these relationships hold can we continue to say:

This is a representation successor.

Why you can’t just find the “latest candidate” by path

A more dangerous shortcut is:

The path is all /doc/, so let’s just grab the latest candidate for this path and use it.

This loses formal lineage.

Because a physical path may have gone through:

  • old Unit ID;
  • representation successor;
  • source successor;
  • revision;
  • multiple Snapshots.

“Latest” only means:

It is newer in time.

It does not prove:

It is the legal predecessor of the current finding.

So the formal workflow must bind:

An explicit replacement relation from old Unit → current Unit.

And not:

path-based latest candidate.

The successor baseline also cannot be guessed from the target translation

Another key task of representation reconciliation is to establish for Generation:

current protected baseline.

The ideal scenario is:

Plaintext
old passed raw response
+
source-owned deterministic mapping
→
current protected baseline

Then this new baseline must restore to:

Byte-for-byte identical reviewed predecessor candidate.

If there is any difference after restore, it means:

The bridge cannot prove itself to be a pure representation transition.

At this point, it must fail.

Because the successor’s goal is:

To change “how it is represented”.

Not:

Secretly changing the “already reviewed translation”.

Why the baseline must restore to the exact same old candidate

Assume the old candidate has already been reviewed by the Reviewer.

Now only the representation has changed.

Before Generation actually executes the new revision, the new baseline should still represent:

The same old translation.

So it must satisfy:

Plaintext
restore(new protected baseline)
==
old reviewed candidate bytes

Only this can show that:

The new baseline just swaps the same target into a new editable representation.

If the bytes are different, then a language change has already been introduced.

This kind of change cannot be automatically produced by an engineering bridge.

The representation successor also does not inherit the old A or B as a new conclusion

Even if the old candidate was historically an A, you cannot claim just because the bridge succeeded:

The current successor Unit is automatically A.

Similarly, if what is currently being processed is an old QC B finding, the successor cannot automatically carry over the B as a new language conclusion.

The representation authority only proves:

The machine lineage of the predecessor and successor.

It does not do:

New language quality judgments.

Therefore, the new candidate still needs to go through the following after completing the revision:

Plaintext
validation
→ new Snapshot
→ independent re-QC

Whether it is ultimately an A is still decided by an independent Reviewer.

What the truly legitimate chain is this time

For this kind of situation where “a formal B finding exists, but the old representation cannot express the revision”, the correct chain is closer to:

Plaintext
Old QC B
→ ordinary revision capability failure
→ preserve old failure evidence
→ representation successor authority
→ current successor Unit
→ create new exact revision using the same original B finding
→ Generation
→ validation
→ successor Snapshot
→ independent re-QC
→ A-only finalization

There are two key points here.

First:

The original finding was not rewritten.

Second:

What was added in the middle is a representation bridge, not a new language judgment.

Why we must continue to use the original finding

Assume the Reviewer had already formally determined:

A certain visible label translation needs to be modified.

Later, engineering discovers:

The protector incorrectly protected it.

You cannot therefore fabricate a new language finding:

“Because the protector has a bug, please translate Documentation.”

Because a protector bug is:

engineering necessity.

Not:

A new Reviewer language judgment.

So after the representation successor is established, the new revision should still consume:

That original B finding.

This is the only way the causal chain can remain intact.

Engineering proof also cannot impersonate a Reviewer finding

The reverse is also true.

Engineering can prove:

protected-natural-language-unrepresentable.

Meaning:

The current formal representation cannot express the authorized natural language revision.

This proof can authorize:

Establishing a representation successor.

But it cannot authorize:

What the language should be changed to.

Even less can it decide for the Reviewer:

Whether this is B, C, or D.

So we must strictly distinguish between:

engineering proof

And:

language finding.

One proves:

Insufficient tool capability.

The other proves:

A language quality issue exists.

Why we still insist on fail-closed here

Actually, a “smarter” system could also be designed.

For example, the machine discovers:

The token is actually just Documentation.

Then automatically judges:

This doesn’t look like code, temporarily open up editing capability.

This might make the user experience much smoother.

But the problem is:

On what basis does the machine determine that it is not an identity that must be kept exact?

And on what basis does it determine:

That this particular instance can be opened up, while tokens of the same kind cannot?

As long as this judgment lacks formal source-owned proof, the safest outcome is still:

Stop.

That is:

If the representation cannot legally express the revision, fail closed.

Although this adds an extra engineering step.

But at least it won’t break machine safety boundaries just to complete a translation.

What the protection mechanism truly needs is correct classification, not absolute conservatism

This case made me rethink the protector.

It is not a:

Filter where the stricter the better.

But rather more like a:

Language permission allocator.

It determines:

Which bytes the model can edit.

So classification errors go in two directions.

The first kind:

Misclassifying technical content as natural language.

The risk is:

The model modifies machine identity.

The second kind:

Misclassifying natural language as technical content.

The risk is:

Legitimate language revisions can never be completed.

Both are correctness bugs.

A protected token is essentially a capability

If understood from a capability perspective, the whole problem becomes clearer.

Generation seeing ordinary prose means:

It possesses the capability to modify that prose.

Generation only seeing the token:

Plaintext
⟦P42⟧

Means:

It does not have the capability to modify the internal bytes of the token.

So when the Reviewer finding points to natural language inside a token, what is really happening is:

Language authority has authorized the change, but transport capability has not authorized the change.

The two layers of authority are inconsistent.

This is the root cause of why the ordinary revision cannot continue.

So a complete Bundle does not mean the task is necessarily “executable”

Previously, I was more inclined to understand the Generation Bundle as:

As long as the bundle is current, the identity is correct, and all files are complete, the model can start working.

This case made me realize I need to ask one more question:

Does the Bundle representation truly possess the editing capability required to close the finding?

The Bundle can have:

  • Correct SHA;
  • Correct inventory;
  • current-check PASS;
  • Correct predecessor;
  • Correct finding;

But if the required prose is protected as an opaque token:

The task still cannot be executed.

This is not Bundle transport corruption.

It is:

formal editing capability mismatch.

Restricted transport and formal representation replacement also cannot be conflated

Some special revisions in the project use restricted transport.

For example:

Only allowing modifications to certain teaching comment bodies.

This transport projection can temporarily restrict Generation’s editing area.

But it is only:

internal revision transport.

It does not necessarily equal:

formal Page representation.

So just because a certain restricted decoder once successfully restored a candidate, you cannot turn around and claim:

It can act as the formal baseline for an ordinary QC revision.

If the formal source/input/Unit identity has not undergone a corresponding replacement, the transport bridge must be proven separately.

You cannot splice a few tokens together and forge a new representation.

The same-unit bridge solves another class of problems

Another situation is:

The formal Unit ID has not changed, and the source/input has not changed either.

But the raw response produced by a previous restricted transport cannot be continued to be used by the ordinary QC revision decoder.

This problem is not:

formal representation replacement.

Because the formal Unit has not changed at all.

It is more like:

A capability bridge between different editing transports within the same Unit.

So what is needed is:

same-unit transport reconciliation.

Not forging:

old Unit → new Unit replacement.

Both scenarios look like “the old baseline can’t be used”, but the authority is completely different.

Why these representation issues need to be broken down so finely

Because if they are all categorized as:

protector has issues.

The handling approach can easily turn into:

Plaintext
Fix protector
→ rerun

But here there are actually at least three different situations.

The first:

current parser classification error, causing formal Unit representation drift.

Needs:

representation successor.

The second:

The formal Unit is unchanged, but the old restricted transport cannot execute the ordinary QC revision.

Needs:

same-unit bridge.

The third:

The source/target binding of certain protected literals in the historical target itself cannot be uniquely proven.

May need:

machine authority or independent semantic reconciliation.

They cannot borrow authority from each other.

Why the machine cannot guess mapping by occurrence order

There is also a typical ambiguity.

Assume a certain technical literal appears once in the source.

But it appears twice in the old target.

If the old representation did not save enough binding evidence, the machine may not be able to determine:

Whether this occurrence in the source corresponds to the first or second occurrence in the target.

The simplest algorithm of course is:

Pick the first one.

Or:

Pick the one closest to the context.

But these are heuristics.

The formal workflow cannot simply because:

Both choices ultimately seem to restore fine.

Assume the bindings are equivalent.

Because different bindings can affect:

The positions allowed to be edited subsequently.

So when it cannot be uniquely proven:

unknown.

Instead of:

Guessing one.

Representation bugs and language bugs should be fixed separately

This point is particularly important for recovery costs.

If the Reviewer has already given a B, and later it is discovered the protector classification was wrong.

You cannot simply describe the whole event as:

Translation failed.

A more accurate breakdown is:

Plaintext
Language layer:
Reviewer finding valid

Engineering layer:
current representation cannot execute this finding

So first fix:

representation capability.

Then continue to consume:

the original language finding.

This way the Reviewer is not asked again:

To judge the same issue once more.

And Generation is not asked:

To force it on an illegitimate baseline.

This forms a good contrast with the previous article on source replacement

The situation in the previous article /translation/ was:

The source itself truly needs to change.

So it needs:

source replacement successor.

The situation in this article is:

The source bytes have not changed.

What has changed is:

How we correctly identify and protect this source today.

So what is needed is:

representation successor.

Both types of successors adhere to the same principle:

Predecessor is preserved.

But the historical object being protected is different.

The former protects:

old canonical source.

The latter protects:

old formal representation.

Why historical representations are also worth preserving

Some might feel:

The old protector clearly had a bug, why keep that incorrect representation?

Because it explains:

How the formal artifacts at the time were generated.

If the old Generation, raw response, candidate, and QC are all bound to the old token mapping, then after deleting the old representation, it will be impossible to reconstruct in the future:

Why that candidate was legitimate at the time.

So:

Incorrect engineering judgments can be corrected by successors, but historical facts cannot be erased.

This is the same philosophy as keeping the old source immutable.

The new representation should not require old history to pass today’s protector again

This is also a very important point.

If the current protector has been fixed, then the historical representation likely:

Would no longer be generated under today’s rules.

But you cannot therefore say:

The historical artifact is invalid.

Historical validation should ask:

Is the preserved old representation self-consistent with the raw/candidate/evidence at the time?

Current validation asks:

What representation should today’s current source generate?

These two questions must be separated.

Otherwise, every parser evolution could lead to:

All historical evidence becoming invalid.

Then it would be impossible to truly maintain long-term provenance.

The value of the successor lies in connecting these two eras

The representation successor essentially says:

I know what the historical formal Unit is.

I also know what the current formal Unit is.

I can use deterministic source-owned evidence to prove that they correspond to the same physical Page and the same canonical source.

Therefore:

Plaintext
historical representation
→ explicit reconciliation
→ current representation

Instead of:

Plaintext
History is outdated
→ discard
→ only recognize the latest

This is the meaning of successor lineage.

When fixing classification, you also can’t conveniently expand the editable scope

Assume the real problem this time is only that:

The heading navigation label Documentation was incorrectly protected.

When fixing the parser, you should try to:

Only reclassify this type of truly visible natural language as editable prose.

You cannot conveniently also make:

  • URL;
  • tag;
  • href;
  • id;
  • code/API;
  • link binding;

All open to the model.

That is to say:

When fixing under-classification and over-protection, both should maintain minimal boundaries.

Why this kind of problem is well-suited for machine proof, not human guesswork

Whether the representation has changed essentially involves many facts that can be mechanically proven.

For example:

  • Whether the source bytes are the same;
  • Whether the physical path is the same;
  • Whether the old/current input SHA differs;
  • Whether the Unit ID has changed;
  • Whether the route is the same;
  • Whether the package is the same;
  • Whether the dependency identity is the same;
  • Whether it restores to the same reviewed candidate after rebase.

These should all be left to the machine.

The Reviewer should not be asked to judge:

Whether two Unit IDs are “basically the same page”.

The Reviewer should continue to focus on:

Language quality.

The Reviewer also should not be responsible for fixing the representation

Similarly, the Reviewer finds:

Documentation should be fixed.

And has already completed their language responsibility.

The Reviewer cannot be asked:

To also decide how this token should be re-bound.

That belongs to:

repository engineering / representation authority.

Otherwise the Reviewer would simultaneously assume:

  • language judgment;
  • tokenizer semantics;
  • token mapping;
  • historical lineage.

The roles would quickly spiral out of control.

Generation even more so should not create its own mapping

Generation’s responsibility here is equally simple.

If the baseline provided by the Bundle is legally editable:

Modify according to the finding.

If the required content is protected, and the mapping cannot be expressed:

Stop.

It should not:

Guess what ⟦P42⟧ is on its own, and then construct a new token mapping.

Because that would let the language model in turn define:

machine authority.

This is one of the things that should be avoided most.

“0 output” is sometimes the most correct result

From a production efficiency perspective:

Plaintext
0 output

Is very frustrating.

Because the model call has already happened, yet not a single formal candidate was obtained.

But from a fail-closed perspective, it might actually show that:

The safety boundary worked normally.

If the only way to complete the task is:

Modifying a protected token that is not allowed to be modified,

Then refusing to output is the correct behavior.

What really should be fixed is not:

Making the model bolder.

But rather:

Fixing the formal representation contract.

The greatest value of this kind of failure is exposing a “workflow capability gap”

An ordinary language B indicates:

The candidate has quality issues.

A representation capability failure indicates something else:

The current workflow lacks the capability to execute an already legally authorized revision.

The latter is actually closer to:

infrastructure bug.

So the handling approach should also be completely different.

It cannot be resolved by:

Trying Generation a few more times.

Because no matter how many times the model is swapped, as long as the protected baseline remains unchanged:

The capability still does not exist.

Retries cannot solve representation inexpressibility

This is also why retry and revision must be separated.

If the failure is:

  • token loss;
  • restore malformed;
  • Generation accidentally outputting the wrong format;

You can consider:

retry.

But if the failure reason is:

The natural language the Reviewer wants to change is actually inside an opaque protected token,

Then retrying a hundred times will yield the same result.

Because the problem is not:

The model didn’t do a good job this time.

But rather:

The task has no legitimate solution in the current representation.

So failure diagnosis must first determine “which layer the problem is on”

When encountering a revision failure, at least the following should be distinguished:

Generation output error.

Validator rule error.

Insufficient representation capability.

Historical binding cannot be proven.

Transport bridge incompatible.

If they are all uniformly handled as:

retry.

It not only wastes quota, but may also produce more and more meaningless failure artifacts.

The representation successor ultimately is still not a PASS

Even if engineering has established:

A legal successor from old Unit → current Unit.

It only shows that:

The capability to execute the original finding now finally exists.

The next step is still:

Plaintext
new revision Generation
→ restore
→ validation
→ Snapshot
→ independent re-QC

Representation reconciliation itself does not produce:

A.

This point is very similar to the source replacement authority.

It solves:

Input and lineage.

Not:

Language quality.

A layering principle I now endorse more

Having reached this point, I increasingly feel that at least three things should be clearly distinguished in the formal translation workflow.

The first:

Is there a language issue?

Judged by the Reviewer.

The second:

Is Generation authorized to modify this scope?

Determined by the finding and revision scope.

The third:

Does the current representation have the capability to express this change?

Determined by the machine contract.

Only when all three hold simultaneously:

Plaintext
Legitimate finding exists
+
Legitimate revision authorization exists
+
Executable editing representation exists

Can Generation truly have the possibility to complete the task.

The principles most worth keeping this time

After going through this kind of representation failure, I think the rules can be condensed into the following.

First:

The goal of protected representation is not to protect as much as possible, but to accurately distinguish between editable natural language and unmodifiable machine semantics.

Second:

Misclassifying technical content for the model is a bug; incorrectly protecting ordinary natural language is equally a bug.

Third:

A Reviewer can legitimately spot a problem that Generation currently has no capability to modify. Language judgment and editing capability are two different layers of authority.

Fourth:

If a formal finding points to opaque protected content, Generation must not be allowed to modify the token, delete the token, or reconstruct token mapping on its own.

Fifth:

You cannot re-Protect from the restored target to guess the current formal mapping; the representation must be determined by the canonical source authority.

Sixth:

After fixing the parser / protector, if the protected input or Unit identity truly changes, an explicit representation successor must be established, rather than rewriting the old batch.

Seventh:

Old zero-output failures, raw, candidate, QC, and other historical evidence should all remain immutable; successor capabilities advance through successor lineage.

Eighth:

The representation successor only proves the machine relationship between the old/current formal Unit; it does not generate new translations, nor does it inherit a new language A.

Ninth:

The new revision still consumes the original Reviewer finding, and then goes through validation and independent re-QC.

Tenth:

The same physical source does not mean it is always the same formal TranslationUnit; a real change in the representation contract can also produce a new Unit identity.

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

The value of the protection mechanism lies not in making the model “unable to touch anything”, but in making the model touch only what it truly should touch.

Under-protection will let the model break machine semantics.

Over-protection will prevent legitimate language revisions from happening.

And when this boundary truly changes, the correct way to handle it is not to secretly modify history.

But rather to explicitly acknowledge:

The old representation once existed.

It is no longer sufficient today to express the new legitimate task.

Then, through a formal successor, safely bring the workflow onto the new representation.

This is the only way to maintain a protected translation workflow that can truly evolve over the long term.

系列导航

关于作者 · 持续学习与技术实践

我是一名拥有 15 年以上开发经验的技术从业者，自 2013 年起持续运营个人技术博客，记录工作与个人项目中遇到的真实问题，以及解决问题过程中的探索、实践和思考。

除了技术写作，我也在持续开发和维护自己的独立项目，探索新技术和新工具在实际场景中的应用。我始终相信，没有不值得去解决的问题，也没有不值得去学习的技术。

如果这篇文章对你有所帮助，欢迎浏览博客中的其他文章，也欢迎交流技术经验与想法。

关于我  ·  GitHub  ·  邮件联系

更多文章