A Reader’s Map: What FluentRead Preserves, and Where

FluentRead’s page translator and reading card now give us two views of the same source-context problem. One changes a live document while protecting page ownership; the other analyzes a selected passage while limiting what a model may see and do. This checkpoint connects those already-established ideas into a practical map: source context, ownership, permission, and lifecycle. The map helps a reader compare the next set of FluentRead features without assuming that a cohesive reading experience must come from one universal engine.

One source, two kinds of ownership

The page translator and reading card both begin with source material that should remain inspectable, but they own different things. Page translation owns a temporary display layer on a live document. Its responsibility is to discover eligible text, request translations, place them beside or in place of the appropriate original, and remove only the work it still owns when the reader restores the page or another translator takes over. The page can change while all of this is happening, so ownership is tied to the current page state, not merely to the location where a request began.

The reading card owns a narrower conversation around a selected passage. Its primary question is not “which text on this page should be rendered next?” but “what does this selected text mean, how is it structured, or how might the reader use it?” Paragraph context is an explicitly permitted supplement. The model can use a captured paragraph when the setting allows it, but the reading loop does not gain authority to search the page for more. Here, ownership means that the selected text and its authorized context remain the object of analysis even when the model is invited to explain an ambiguity.

These boundaries produce different kinds of safety. A page result is unsafe when it is inserted into a changed or externally owned DOM region. A reading-card result is unsafe when it silently broadens the subject, carries an earlier action into a new one, or treats source text as an instruction to execute. Both problems can be described as context loss, but their remedies differ. The page needs current owner and source checks before a DOM commit. The card needs a permission boundary around context and an action boundary around the model’s task.

The shared principle is therefore not “everything goes through one context manager.” It is simpler: a result should remain traceable to the source and intention that authorized it. FluentRead’s original/translation display makes page output comparable with its source. The reading card’s selection and paragraph scope make explanation comparable with the evidence supplied to the model. In both cases, the reader can ask not only whether an output sounds good, but what it is an output of.

flowchart LR Source["Original source"] --> PageInput["Page text and DOM state"] Source --> Selection["Selected text"] PageInput --> PageOwner["Page ownership and generation"] Selection --> Permission["Selection and permitted paragraph"] PageOwner --> PagePath["Translation request and bilingual commit"] Permission --> CardPath["Bounded reading-card request"] PagePath --> PageReview["Compare or restore page"] CardPath --> CardReview["Check answer against source"] PageReview --> Boundary["Reader-visible boundary"] CardReview --> Boundary Boundary --> Media["Apply the same questions to other media"]

This distinction also explains why an integrated product can contain separate user choices. A reader may translate a page with a regular machine service, then open the reading card with a configured AI model.