The request for the perfect writing tool
Constructed opening claim. “Which system is best for authors?”
The question is understandable and almost impossible to answer honestly. Best for what form of work? Best for a writer composing alone on one device, a distributed editorial team, a small press preserving a backlist, a contributor using assistive technology, a reporter handling confidential material, a classroom, a translator, or a studio making a complex illustrated book? Best in the first week, over a decade, after an account changes, during a collaborative emergency, or at the moment a work must become a readable and durable publication?
The request for one winner contains several values that do not move together. A system can make a visual layout easy to manipulate while making structured reuse difficult. It can offer rapid shared editing while asking a group to accept a new privacy or membership dependency. It can make a task simple for a familiar expert while placing an unnecessary cognitive burden on a new or disabled participant. It can preserve a final file while losing the context needed for later correction. It can lower an obvious price while moving costs into maintenance, export, coordination, or access recovery.
The next authoring system is therefore not a product waiting to be named. It is a question of how a tool or arrangement carries thought through composition, revision, collaboration, accessibility, preservation, publishing, and later use. No single architecture or interface can maximize every value in every setting. The responsible alternative to a winner claim is a transparent comparison that lets different values remain distinct.
This paper introduces the Publication-Path Comparison Canvas, an original Wexley capstone instrument for comparing two or more bounded authoring arrangements. It records a work boundary, people and roles, agency, representation, accessibility, privacy and collaboration, recovery and durability, provenance, economics, publishing handoff, evidence quality, and an explicit non-conclusion. It does not create a universal score, certify software, recommend a purchase, determine legal compliance, or replace user research. It gives a reader a way to ask a better question: which arrangement advances which value for this work, at what cost, and with what remaining uncertainty?
A tool is a path, not a feature list
Feature lists are tempting because they look comparable. One system has comments, another has version history, another has templates, another works offline, another uses AI, another exports files. The list rarely says what a feature means in the actual route from thought to publication.
A comment can be a useful editorial conversation, an inaccessible pane, a private annotation with unclear retention, or a dependency that cannot travel in an export. Version history can support recovery, expose confidential work, create an uninspected archive, or offer only a partial representation of change. A template can lower setup cost for one project and force a misleading structure onto another. An AI suggestion can preserve agency when it offers meaningful alternatives and recovery, or it can silently substitute an action the writer did not understand or choose. A simple “yes/no” feature comparison cannot hold those conditions.
The Canvas begins with the publication path: how a bounded work moves from a working thought through drafting, revision, editorial exchange, access, production, release, correction, and preservation. The path does not have to include every phase in every comparison. It only has to make the comparison’s scope visible.
This is why agency, accessibility, durability, privacy, and craft should not be treated as optional columns added after the “real” technical evaluation. They are conditions under which technical features acquire meaning.
The values are related, but not interchangeable
The following dimensions frequently appear together in authoring debates. They should be held apart long enough to be examined:
| Dimension | The comparison question |
|---|---|
| Agency | Can the person understand, choose, refuse, revise, recover from, and attribute material changes in this bounded task? |
| Representation and craft | Does the system make the relevant text, structure, layout, source relation, or production form legible for the editorial operation at hand? |
| Accessibility | Can different people perceive, navigate, operate, understand, authenticate, and receive the published result through the path? |
| Privacy and collaboration | What material, membership, permission, delivery, and record conditions arise when work is shared? |
| Durability and recovery | What can be retained, restored, migrated, checked, or continued when a device, account, collaborator, or service relation changes? |
| Provenance and accountability | What claims about change, contribution, source, or status are useful to make inspectable, and what cannot those claims prove? |
| Economics and maintenance | Which charges, labor, dependencies, access conditions, and exit costs belong to the work over its stated horizon? |
| Publishing handoff | How does a working manuscript become a readable, discoverable, accessible, and maintainable publication or release? |
The values can conflict. Increasing one may be worthwhile, but should not be described as a free improvement. A more detailed activity record may help a correction inquiry while increasing privacy exposure. A rich visual page tool may support spatial craft while requiring an inaccessible drag-only operation. Stronger group protection may require a more demanding access and recovery process. A format that travels easily may lose a layout relation that a particular work needs. A lower monthly charge may move maintenance labor to the person least able to absorb it.
The first conclusion of a good comparison is often not “A is better than B.” It is “A protects this value under this condition; B protects another value under another condition; neither claim should be generalized yet.”
Standards can organize inquiry without becoming the answer
External frameworks are useful when they clarify a question without pretending to decide it.
WCAG 2.2 frames accessibility requirements as technology-neutral, testable success criteria while acknowledging that the guidelines do not address every user need. [1] That makes it a helpful reminder that accessibility needs evidence at the interaction and output level, not a vague promise that a tool is inclusive. It does not make WCAG a complete evaluation of an authoring environment, a document, or a publication path.
NIST’s AI Risk Management Framework organizes risk-management activity around govern, map, measure, and manage, and the NIST playbook cautions that its suggestions are voluntary rather than a one-size-fits-all checklist. [2] This paper borrows the shape of that restraint, not the framework’s domain. An authoring comparison needs a named purpose, mapped context, evidence, and a way to manage unresolved trade-offs. It should not be an AI risk exercise merely because a tool contains AI.
NIST’s Secure Software Development Framework likewise emphasizes lifecycle practices rather than launch-time assurance. [3] Its relevance is bounded: authoring systems are not software-development programs, and authors are not required to conduct security engineering. Still, a tool that is easy today but impossible to recover, update, or continue tomorrow has a publication-path condition worth recording.
Privacy deserves the same contextual treatment. The MLS architecture describes group collaboration as involving identity, delivery, policy, membership, and protected content. [4] It does not specify an editorial workspace. It provides a reason not to reduce collaborative privacy to a single encrypted-content label. The comparison should state who participates, what they can do, how their role changes, and what recovery or metadata condition has not been tested.
The Publication-Path Comparison Canvas
The Canvas is a non-validated Wexley teaching instrument. It compares bounded arrangements, not brands. An arrangement may be a tool, a toolchain, a local practice, a shared service relation, or a publishing workflow.
| Field | Record this | Do not infer |
|---|---|---|
| 1. Work and time boundary | Work type, publication goal, people, format, time horizon, and comparison question. | That a result applies to every writer, genre, organization, or future phase. |
| 2. Arrangement description | The actual tools, services, interfaces, and handoffs in each path. | That a named product describes all configuration or practice. |
| 3. Agency and choice condition | Meaningful choices, visibility of interventions, alternatives, recovery, attribution, and refusal paths. | A determination of authorship, intent, or autonomy. |
| 4. Representation and craft condition | Text, structure, layout, source, annotation, and production representations relevant to the task. | That one representation is universally superior. |
| 5. Accessibility condition | Input, navigation, perception, cognitive, authentication, assistive-technology, and output considerations. | Conformance or inclusion without testing and user evidence. |
| 6. Privacy and collaboration condition | Material scope, roles, permissions, membership change, delivery, and record questions. | Confidentiality, trust, or compliance guarantees. |
| 7. Durability and recovery condition | Copies, exports, formats, dependencies, restoration, maintenance, and exit questions. | A preservation promise or legal right to portability. |
| 8. Provenance and accountability condition | Useful records of source, change, contribution, status, and their audience/purpose. | Truth, quality, authorship, responsibility, or a complete history. |
| 9. Economics and maintenance condition | Known charges, labor, access, support, dependencies, and transition conditions. | A total-cost calculation or affordability verdict. |
| 10. Publishing handoff condition | How work becomes a publication, including production, accessible reading, discovery, correction, and update routes. | Reach, sales, or reader reception. |
| 11. Evidence and counterweight | Source, observation, user check, or test supporting each record, plus a material trade-off. | That one favorable feature decides the comparison. |
| 12. Decision boundary and non-conclusion | What next test, stakeholder conversation, or bounded decision the comparison supports. | A universal winner, procurement decision, or product endorsement. |
The Canvas should be filled across rows, not as separate essays about each arrangement. If Path A is said to be “more accessible,” the comparison must name the task, user condition, evidence, and counterweight. If Path B is said to be “more durable,” it must say whether that means export, recoverability, format, custody, maintenance, or some other relation.
A constructed comparison
The following example is fictional. It does not evaluate an actual product or workflow.
Initial claim: “The new authoring system is better because it combines drafting, design, collaboration, and publication.”
Bounded comparison: A fictional small press is preparing a short illustrated nonfiction title over six months. Path A uses one integrated online authoring service. Path B uses a local structured text editor, a separate shared-review space, and a production handoff. The press’s question is not which path is best in general; it is which conditions each path creates for this title, its contributors, and its intended output.
| Canvas field | Path A: integrated service | Path B: separated toolchain | Comparison discipline |
|---|---|---|---|
| Work boundary | Drafting, illustration review, copyediting, and accessible digital release are proposed in one space. | Drafting, review, and production are divided among connected spaces. | Neither path represents all future titles. |
| Agency | Suggestions and layout changes are visible in one interface; ability to refuse/recover a proposed automation is unverified. | More steps are explicit; handoffs may make options harder to see. | Do not infer agency from integration or separation alone. |
| Representation and craft | Visual page work is immediate; structured reuse and export treatment are unverified. | Structure is explicit; visual page rehearsal requires another stage. | Different representations help different operations. |
| Accessibility | One accessible-release claim is proposed; authoring, review, authentication, and reader output all require separate evidence. | Multiple interfaces may create more access paths and more barriers. | A single final-format claim is insufficient. |
| Privacy and collaboration | Centralized roles may simplify review; membership, records, and delivery conditions remain unknown. | Separate spaces may reduce scope in one step and complicate it in another. | No confidentially result follows from architecture alone. |
| Durability and recovery | One account may hold context; export, restoration, and exit treatment are untested. | Several copies may exist; keeping them aligned may create maintenance and recovery work. | More copies are not automatically more recoverable. |
| Provenance | Central history may show changes; audience, retention, and meaning of records are unknown. | Handoffs may create discrete records; relationship between them may be incomplete. | A trace does not prove authorship or quality. |
| Economics | A recurring charge is documented; labor, exit, and project-end condition are not. | Lower service charge is proposed; maintenance and coordination labor are not logged. | Price is not the full cost. |
| Publishing handoff | Publication may be close to the drafting surface; output validation is untested. | Production handoff is explicit; translation between stages may lose context. | Publication is a path, not an export button. |
| Next evidence | Test one accessible authoring/review/release path and one representative export/recovery path. | Test the same paths plus a cross-tool comment/citation handoff. | The Canvas cannot declare a winner. |
The example has not selected a system. It has exposed where an integrated system could make a handoff easier and where it could concentrate dependency, and where a separated toolchain could make structure explicit while introducing coordination work. The next step is testable, not ideological.
Publication is a reader path as well as an author path
An authoring arrangement may feel excellent to the person making a document and still fail at the point of publication. The final reader may encounter an inaccessible export, a page that does not reflow, an omitted alternative description, a broken link, a poor search record, a version without a correction route, or a file whose status cannot be identified. The authoring comparison therefore needs to cross the boundary between production and use.
This does not mean every writer must become a format engineer. It means that the comparison should name the intended reader and publication outcome early enough that the authoring path cannot treat output as an afterthought. A visual layout choice, a source-handling convention, a collaboration permission, or an AI-generated contribution can shape the reader’s final access and the publisher’s later ability to correct or preserve the work.
The publishing-handoff field is deliberately broad. It can concern a print proof, a reflowable digital edition, a web article, an audio route, a data-supported publication, or another bounded object. The goal is not to force all works into one future-proof format. It is to ask what the working arrangement must carry across the particular handoff that matters.
Evidence has a hierarchy of strength
The Canvas should show the kind of evidence behind each entry. A documented fact about a current arrangement is different from a controlled test, a user observation, a participant’s report, a proposed feature, and an unresolved unknown. Without that distinction, a hopeful product claim can sit beside a tested accessibility path and look equally established.
One simple notation is enough:
| Evidence state | Meaning |
|---|---|
| Documented | A source, configuration, policy, or observed behavior has been identified for the stated boundary. |
| Tested in this setting | A representative task or path has been tried by a relevant participant or team. |
| Reported | A participant or stakeholder describes an experience that still needs scope and corroboration. |
| Proposed | An intended workflow or feature has not yet been demonstrated. |
| Unknown | The comparison has no evidence sufficient to make the claim. |
These states are not scores. They keep the comparison honest about what it knows. An arrangement can be promising and still have unknown recovery conditions. Another can have a documented export but no evidence that a disabled editor can use the authoring surface. The next action follows from the weakest material condition, not from the longest feature list.
Use the Canvas as a sequence of small decisions
Start with one title, one team, or one publication pathway—not a corporate platform strategy. Compare only the arrangements that are genuinely available. Choose one or two decision boundaries, such as a pilot chapter, a sensitive review period, or a final-production handoff. Then collect the smallest evidence that could change the decision.
After a pilot, do not declare the framework complete. Update the Canvas with what was tested, what changed, and what trade-off became visible. A path that worked for a text-only essay may not work for an illustrated book. A collaboration method that works for two people may need a different access arrangement for twenty. A reader-output test may change the weight given to a convenient drafting feature.
The repetition is a strength, not an admission of failure. Authoring systems change because works, people, and publication conditions change. A comparative framework should make those changes visible without making every choice permanent.
A comparison should admit value conflict
The Canvas includes no weighted score by design. Weights look neutral while hiding the people and purposes that assign them. A publisher may care most about production repeatability; a writer may care most about a low-friction accessible input path; a reporting team may prioritize bounded collaboration; a preservation-minded editor may prioritize export and recovery. These priorities may be compatible, but they need to be stated rather than silently embedded in a ranking.
That does not make comparison impossible. It makes it accountable. A team can decide that a known accessibility barrier is decisive for its purpose, or that an untested export condition blocks adoption until evidence is gathered. It can set a narrow decision boundary: “Use this arrangement for a pilot chapter if the review path is accessible and the manuscript can be recovered in a representative test.” That is not a claim that the arrangement is best for all authors.
Provenance gives a useful final restraint. C2PA specifies structures for verifiable assertions and explicitly cautions against interpreting validated provenance as a value judgment about whether content is good or bad. [6] The technical setting differs from manuscripts, but the intellectual lesson travels: a record can make a claim inspectable without finishing the judgment. An authoring-system comparison should make its criteria, evidence, and trade-offs inspectable without pretending to transform them into an objective winner.
The next system is a question of conditions
The future of authoring is not guaranteed by more features, more automation, more cloud integration, more local control, or more visible layout. It lies in whether a toolchain helps particular people turn thought into publication while keeping choices, access, collaboration, durability, and responsibility legible.
Return to the opening claim: “Which system is best for authors?” After the Canvas, the question becomes:
For this work, these people, this publication path, and this time horizon, which arrangement better supports our stated priorities, what trade-offs does it create, what evidence is missing, and what bounded decision can we responsibly make now?
That is a harder question. It is also the one a next authoring system should be able to survive.
References
[1] W3C, Web Content Accessibility Guidelines (WCAG) 2.2 (2024), https://www.w3.org/TR/WCAG22/.
[2] National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework 1.0 (2023), https://doi.org/10.6028/NIST.AI.100-1.
[3] National Institute of Standards and Technology, Secure Software Development Framework, SP 800-218 (2022), https://doi.org/10.6028/NIST.SP.800-218.
[4] R. Barnes et al., The Messaging Layer Security (MLS) Architecture, RFC 9750 (2025), https://www.rfc-editor.org/rfc/rfc9750.html.
[5] National Institute of Standards and Technology, Recommendation for Key Management: Part 1—General, SP 800-57 Part 1 Rev. 5 (2020), https://doi.org/10.6028/NIST.SP.800-57pt1r5.
[6] Coalition for Content Provenance and Authenticity, C2PA Technical Specification 2.4 (2026), https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html.