The screen that shows your slide and the engine that writes your file already exist, and it is natural to assume that connecting them is a matter of wiring. It is not, and this page says exactly why. What separates the two is the identity of each element, lost somewhere along the path between the document and the rendering you see.
Changing it where you are reading it
The fix comes out as a recorded operation, not a new file nobody tracks
The cycle most teams know goes like this: you open your material on screen, find the error, download the file, fix it in an office program, upload it again. In the end you have two files and no record of which one changed what. By the third round, nobody on your team can say with certainty which version is the good one.
The direction here is different. You fix the text on your slide that is already open, and your correction does not hand back a loose file: it becomes a named operation, executed by the engine over the structure your document already has, with a record of what changed and against which version. It is the same design that already backs translation, applied to editing a single sentence. What changes is the size of the request, not its nature, and that continuity is what makes editing on screen worth having instead of being one more window.
Element identity is what makes an edit addressable
Without it, a change on screen is a request the engine cannot resolve
When you click a text box and type, something needs to tell the engine which box in your file that was. Not the position on your screen, which changes with zoom and font, but the identity of that element inside your document: the join key the input reading assigned to it and that the engine uses to write back in the right place.
That key is what separates a checkable edit from a guess. With it, the engine opens your file, finds the exact element, changes that one and leaves everything else untouched, which is the same boundary described in layout preserved. Without it, the only thing left is to guess by visual proximity, and guessing inside a file of yours that goes to a client is precisely what this house does not do.
What is missing, said precisely
The page rendering arrives without identity, and that is a consequence of the path, not an oversight
The component that edits your slide on screen is built, and it already speaks that language: every node it lets you edit carries the identity of the corresponding element. The step that writes your file is also built, and it resolves exactly that same key. Both ends exist.
What does not exist is the piece in the middle. The rendering of your page you see today is produced from a final render, and in that step every element stops being an element and becomes stroke and coordinate. The information is not hidden or forgotten: it is destroyed by how the path is built, because a rendering does not hold the notion of a text box. The identity keeps existing, but in the record the input reading produced, not in the picture.
Saying this with this precision has a practical reason, and it is yours. A wiring job gets solved in a week and does not deserve a page; producing a rendering that preserves identity is an architecture decision. You deserve to know which of the two this is before you put the feature on a deadline of your own.
Where this stands today
Direction declared, with the gap located and no verb in the present tense
This page describes a capability that has not shipped, and the information it has to give is the exact location of the gap. It is not a generic roadmap item: both ends are measured, the missing piece is named, and the two possible outcomes are too, which are the rendering gaining a second mode or a new step being born for this.
What already works today, without an editor, is seeing your entire material on screen alongside what the engine extracted from it, and that is in see. The conversation that produces the change, when it exists, is the subject of agentic editor.
The state, said in full and before you ask. The gap was measured on 2026-08-26 and checked again on 2026-09-02. The editing component carries the join key on the nodes it lets you edit; the page rendering produced today carries none, and the count is zero across the whole engine, not small. Editing on screen is recorded in the internal roadmap as a post-launch item, decided on 2026-07-10.
And what this page does not claim. There is no deadline here, and there is no deadline because the missing piece is an architecture decision not yet made. When it is made and the edit exists, it enters this page with the date of the first measured execution, the same way the other capabilities did.