PasteLint

Engine Room

Transparent notes on how PasteLint’s deterministic preparation tools report their work.

A Prepared Handoff Is Not an Accepted Outcome

PasteLint can report the preparation it performed. It cannot report what happened after the text left its boundary.

By Guy Teichman

The claim inside the status

A status message can be accurate about an action and misleading about the outcome.

When a tool says that text is ready, complete, or successful, the words do more than acknowledge a click. They make a factual claim about what happened.

That claim can travel farther than the evidence. A browser can observe that it produced cleaned text. It cannot see whether an editor approved the revision, a publishing system accepted the document, a speech service deployed the audio, or a reader understood the result.

The feedback contract introduced in 154631a narrows PasteLint’s language to the operation it can inspect. It reports the transformation and leaves the next decision visible.

The observable result

Four outcomes describe what the preparation action actually did.

Changed
The action returned text that differs from its source.
Unchanged
The action completed and preservation was the result.
Blocked
A required input or prerequisite was missing.
Failed
The action could not return a trustworthy result, so the source remained available.

These are outcomes of a local action. They are not estimates of quality, approval, publication, or downstream success.

The handoff boundary

Only completed stages should appear complete.

Concept Illustration · Does not execute PasteLint

Preparation stops before acceptance

  1. Draft
  2. Reviewed
  3. Prepared
  4. Ready for destination

Evidence boundary: Preparation does not establish publication or downstream acceptance.

Why the boundary remains visible

PasteLint can observe the preparation it performs. Publication, deployment, delivery, and acceptance require evidence from the receiving system.

Text summary: Draft, reviewed, prepared, then ready for destination. PasteLint can report preparation; publication or downstream acceptance requires evidence from the destination.

Limitation: This is a conceptual workflow illustration and does not observe a downstream destination.

Complete concept illustration available without interaction.

PasteLint operates near the beginning of this sequence. It accepts text, performs a selected preparation action, presents the result, and makes the result available for review or transfer. The later stages belong to the person and system receiving the text.

A successful preparation does not collapse those stages into one. Review still has to happen. Copying or transferring output does not establish that the destination was updated. Arrival does not establish acceptance.

The implemented language

The message names the transformation and the remaining review.

  • Clean reports: Text cleaned. Review the repairs, then continue when ready.
  • When Clean finds nothing to repair, it reports: No cleanup needed. The text was preserved.
  • SecondDraft reports: Draft revised. Review the changes before continuing.
  • SSML Builder reports: SSML generated from cleaned text. Review it before final audio.
  • Running the same SSML generation again reports that the SSML already matches its available source instead of claiming another change.

Each message identifies what the tool observed. Each stops before the next unobserved outcome.

What the result does not establish

Preparation and acceptance require different evidence.

Prepared text
Does not mean published.
Generated SSML
Does not mean audio was generated, reviewed, or deployed.
Copied text
Does not mean documentation was updated.
Prepared prompt
Does not mean an AI workflow ran or returned the intended result.
Prepared manuscript
Does not mean a publication accepted it.

The distinctions are ordinary, but status language often erases them. PasteLint keeps them separate because a later system can fail, reject, reinterpret, or never receive otherwise well-prepared text.

Under the hood

One small contract serves three different preparation tools.

The shared browser module accepts only four state names: changed, unchanged, blocked, and failed. It attaches the state to the existing status region and presents the action-specific message. An unknown state is rejected rather than silently translated into generic success.

Clean compares cleaned output with the submitted source. SecondDraft compares its bounded revision with normalized input and rejects malformed results. SSML Builder compares generated markup with the output already present. Empty prerequisites become Blocked; caught execution failures become Failed.

The implementation is shared, but the evidence remains local to each action. The state contract does not become a workflow engine, an approval system, or a monitor for external destinations.

Regression evidence

The claim is checked at the same boundary where it is made.

  • Feedback state foundation verifies the four accepted state names and rejects a generic success state.
  • Homepage empty input status verifies Blocked, Changed, and Unchanged outcomes for Clean.
  • SecondDraft feedback states verifies empty input, a preserved draft, a changed draft, and rejection of an unsafe result.
  • SSML empty action statuses verifies blocked prerequisites, preserved speech text, changed generation, and repeated unchanged generation.

These fixtures establish the tested browser behavior. They do not establish that every downstream destination interprets or accepts the prepared text correctly.

Engine principle

A truthful workflow reports only what has actually happened.

Preparation is valuable. Preparation is necessary. Preparation is not execution.

Canon traceability

The implementation gives three editorial principles a technical boundary.

  • EC-0001, Destination Readiness: preparation is named relative to its next destination without claiming that the destination accepted it.
  • EC-0002, Handoff Discipline: preparation, review, export, delivery, and acceptance remain distinct stages.
  • EC-0012, Preparation Is Not Execution: status language stops at the last outcome the browser can observe.

The Editorial Canon states the durable principles. This implementation record shows one bounded way the current product follows them.

Continue the record

Follow the boundary from principle to evidence.

Related Principles

  • Evidence Before Narrative
  • Verification Before Publication
  • Editorial Transparency

Source Material

  • Editorial ConstitutionThe governing boundary for truthful status, destination preparation, and user review.
  • Editorial CanonDestination Readiness, Handoff Discipline, and Preparation Is Not Execution.
  • Workflow v2Evidence, verification, publication, and acceptance remain separate checkpoints.