Abstract
A network connection is commonly treated as a possession: someone has internet access or does not. That language is too coarse for creative and editorial work. A contributor may be able to connect occasionally yet be unable to submit a correction at the moment a review path requires it. An editor may be able to read a file locally but be unable to verify that it is the current shared copy. A publisher may offer an online route while leaving unexamined the device, energy, account, cost, skill, media, timing, and synchronization conditions that make that route usable.
This paper introduces participation conditions as a teaching vocabulary for those dependencies. It does not claim that offline work is automatically equitable, that continuous connection is always required, or that any particular service solves the problem. Instead, it offers the Participation Condition Matrix, a reader instrument for examining one stated activity at one stated moment. The instrument asks what must hold for a participant to take part, what may proceed locally, what must later be handed off or reconciled, what evidence supports the claim, and what remains unresolved. Its purpose is to replace the slogan “accessible online workflow” with a more exact and more honest question: available to whom, for which activity, at what time, under which conditions?
The correction that cannot travel
Consider a small act of editorial care. Mara, a fictional contributor to the fictional journal Riverline Quarterly, notices that a quotation in her essay has lost its attribution. She corrects the sentence in her local working copy, checks the source note, and prepares a short explanation for the editor. The editorial process, however, recognizes the correction only when it reaches a shared review route before the issue moves forward.
For a brief interval, Mara can open a message. She cannot reliably transfer the revised artifact and the explanatory note through the expected route. Nothing in this constructed scene establishes the quality of a real connection, the attributes of a device, the location of a person, the price of data, the behavior of a service, or the outcome of the publication. Those facts are deliberately absent. The scene is useful precisely because it isolates a question that is often hidden inside more dramatic language about infrastructure.
The question is not whether Mara “has the internet.” The question is what conditions must hold for Mara’s completed correction to count as participation in this editorial workflow.
The answer may include a connection, but it cannot end there. Must the connection be continuous or merely available at a later handoff? Must the contributor possess a particular device at the needed moment? Does a login, authentication event, account status, media-heavy representation, shared current state, or publisher-set deadline make the correction practically impossible to deliver? Can the work be preserved locally without treating the editorial act as complete? If the correction reconnects later, what must be verified before an editor can accept it as current?
These are not objections to connected publishing. Shared review, timely clarification, synchronized release, reader support, publication tracking, and distributed collaboration can all have legitimate reasons to require a current common state. The point is narrower. A workflow becomes exclusionary when it treats its own conditions as invisible and then labels anyone who cannot satisfy them as absent, late, unresponsive, or unprepared.
The International Telecommunication Union’s account of universal and meaningful connectivity offers a useful starting resistance to binary language. It describes six interdependent dimensions: quality, availability, affordability, devices, skills, and security. Its framework also makes an important qualification: meaningful connectivity is not identical to constant connectivity. [1] The qualification does not make local work superior. It does show why a network icon, a coverage map, or a general statement that someone is “online” cannot settle whether a particular creative act is available at the moment it matters.
This paper calls the requirements around such an act participation conditions. The term is not a diagnosis of a person, a region, or a network. It is a way of naming the otherwise unmarked conditions that a workflow requires from a participant.
From nominal access to a condition stack
A person can be classified as an internet user under a broad metric while still encountering barriers to regular, continuous, or autonomous participation. Hernandez and Faith’s analysis of six digital-access surveys in the United Kingdom, United States, and European Union shows why this distinction matters. The article observes that broad measures—such as having gone online in an extended period—can conceal the different frequencies and degrees of independent use that follow nominal access. [2] Its contribution here is methodological, not demographic: a large category can be a poor proxy for a task.
Creative and editorial systems often reproduce that same problem in miniature. A team may say that a document is “available online,” an application is “mobile,” or a submission process is “digital-first.” Those descriptions report a possible route. They do not show that every participant can complete the particular activity that the route makes necessary. The relevant unit of analysis is therefore not a service in the abstract. It is a specific activity: upload a citation correction, leave a response on a proof, verify a current page, review a high-resolution image, join a final-read meeting, or approve a release.
The following vocabulary gives that unit of analysis enough precision to be teachable.
| Term | Meaning in this paper | What the term does not mean |
|---|---|---|
| Participation condition | A network, device, time, location, cost, account, skill, energy, media, or state condition that must hold for a participant to complete a stated activity. | A judgment about an individual’s competence or a place’s worthiness. |
| Nominal access | A broad indication that a person, device, or area can connect at some time or under some conditions. | Proof that a time-sensitive activity is practicably available. |
| Critical activity | The smallest named action whose failure blocks participation in the stated workflow. | The whole workflow, a product category, or an identity category. |
| Immediacy demand | How quickly a response, record, or common state must be available for the activity to count. | A universal argument for live connection. |
| Local fallback | A documented way to retain, prepare, or continue a limited activity before a later handoff. | A guarantee that the shared outcome, privacy, security, or publication is complete. |
| Synchronization question | The state, version, review, or record question that emerges when locally prepared work reconnects to shared information. | A preselected conflict-resolution rule or an editorial decision about authority. |
| Participation threshold | The minimum combination of conditions that must be evidenced before a workflow is called available for a stated participant and task. | A universal score of inclusion. |
This vocabulary changes the question from “Can someone connect?” to “What must be true for this activity to happen?” The change matters because the relevant conditions compound rather than substitute for one another. A participant may possess a functioning device but lack an available connection at the required moment. A connection may be present but a file may be too burdensome for the route. A low-burden file may be available but the participant may need a current shared record, an account event, or a response from another person before the work can become editorially effective. A perfectly usable local draft may still await a deliberate handoff.
The World Bank’s multi-country working paper on mobile internet adoption offers a carefully bounded empirical parallel. Using household and individual survey data from 22 countries in the Global South, it organizes adoption conditions across physical infrastructure, socioeconomic factors, and contextual or perspective factors. Its framework names network coverage and electricity alongside price of devices and data, income, education, location, and related factors; it also cautions that the magnitudes of those relationships vary across settings. [3] The paper does not test literary production or editorial work. It does, however, support the narrower proposition that coverage cannot exhaust the conditions relevant to meaningful use.
An industry overview from GSMA likewise treats affordability, device ownership, and literacy/digital skills as barriers within mobile internet adoption, rather than treating coverage as the whole story. [4] Its value here is limited to category recognition. It is not a local performance report, an explanation of a particular user’s circumstances, or an authority for ranking markets. Together with the ITU and World Bank materials, it gives the teaching instrument a simple obligation: record the condition that is actually being assumed instead of hiding it inside a general label such as access.
The condition stack around a single editorial act
A condition stack is the set of interdependent requirements surrounding a critical activity. It is not a checklist that must always be filled with every possible barrier. It is a way to avoid assuming that the visible condition is the only one. The stack asks which assumptions are active here, for this task, at this moment.
| Condition class | The question a workflow steward should ask | Proportionate evidence | What an answer cannot establish |
|---|---|---|---|
| Connection quality and continuity | Does this activity require a stable connection now, or only a verified later transfer? | Direct observation of the step, task-specific records, or primary documentation for a named feature. | Whether a whole region, community, or participant is reliably connected. |
| Timing and immediacy | At what point must the participant’s work enter shared state? | Editorial workflow description, stated deadline rules, or observation of the named handoff. | That every activity requires real-time coordination. |
| Device and energy | What usable device and energy condition is being presumed at the relevant moment? | Primary systems documentation or a situated assessment. | Affordability, durability, privacy, or suitability for every task. |
| Cost and account | Does participation require paid data, an active account, authentication, a subscription, or a particular access path? | Terms, institutional policy, or actual arrangement evidence. | What a person can afford or whether an alternative service is appropriate. |
| Media and file burden | Could the essential action be represented through a lighter, downloadable, queued, or text-based artifact? | File/format documentation, observed workflow, or bounded institutional guidance. | That smaller files preserve every needed element or solve access universally. |
| Skill and support | What knowledge, instruction, or assistance is necessary to complete the activity? | Usability research, training records, or direct observation. | A person’s capacity from age, place, income, or any demographic marker. |
| State and handoff | What becomes uncertain while locally prepared work awaits shared review, merge, or verification? | Version rules, task description, or primary technical documentation. | Who should hold editorial authority or how every conflict should be resolved. |
The table is intentionally skeptical about its own evidence. A national coverage measure can be useful for policy analysis, but it cannot show whether a particular correction can be transmitted before a particular editorial handoff. The Internet Society’s Internet Resilience Index makes the scale distinction vivid. It is a country-level weighted index that defines resilience as the capacity of an internet connection to maintain an acceptable level of service under faults and challenges. [5] That is a different evidentiary object from a participant’s ability to complete a named action at a stated moment.
The distinction should not become hostility to measurement. It is an argument for matching the claim to the evidence. A resilience index can help an infrastructure analyst ask broad questions. A workflow map can help a publisher see where its own process assumes a continuously shared state. Neither should impersonate the other.
A case from a different domain demonstrates why the scale and role of a task matter. Dell and colleagues studied paper-digital workflows in global-development organizations. In their field setting, participants described intermittent power and unreliable connectivity as complications for data entry, communication, and later transmission to geographically dispersed colleagues. The authors also identify a mismatch between design assumptions and the conditions faced by data-entry workers. [6] This does not prove that creative publishing has the same problems or that paper is an editorial solution. It does illustrate a transferable question: whose work carries the infrastructure requirement after a process has been designed elsewhere?
For a publisher, the person carrying that requirement may be a contributor who must upload a late correction, a copyeditor who must consult a current file, a proofreader who must retrieve image-heavy pages, a volunteer reviewer using intermittent access, or a release coordinator who needs live information. The condition stack makes the burden visible without presuming its solution.
Two routes for one correction
Return to Mara’s fictional correction. The point is not to redesign the journal’s actual process. It is to compare two possible logical routes and notice where the participation conditions change. Neither route is declared better. Both retain unresolved work.
| Route | State of the correction | Connection and immediacy condition | What may proceed locally | Handoff question | What remains unresolved |
|---|---|---|---|---|---|
| Route A — live-dependent review | The correction counts only after it appears in a current shared review space before the editorial moment. | Connection and account access must be available at that time; the shared record is immediately material. | The contributor can draft the correction and explanatory note. | Can the work reach the current review record in time? | Connection, account, shared-state, and editorial-timing conditions. |
| Route B — deliberate deferred handoff | The correction is retained in a reviewable local artifact until a named later handoff. | Connection is required at handoff rather than during every moment of preparation. | Drafting, source checking, and rationale can proceed locally. | What identifies the artifact/version and alerts the editor when connection returns? | Whether handoff, review, confirmation, and release will occur. |
Route A has legitimate uses. A final publication check, an emergency correction, or a joint decision may genuinely require a common, current state. The condition is not a moral failure. It simply needs to be named. Once named, a publisher can avoid pretending that a participant who cannot satisfy it has failed for reasons internal to that participant.
Route B does not remove dependence. It relocates it. The correction can be prepared and preserved as a local artifact, but it may still require an identifiable handoff, a current comparison copy, a response from the editor, and a decision about whether the item has entered the publication record. To call this route “offline collaboration” without those qualifications would be misleading.
The University of British Columbia’s low-bandwidth teaching guidance provides a bounded institutional example of this kind of timing analysis. It asks course designers to consider bandwidth and tool immediacy, suggesting a balance of synchronous and asynchronous material, lower-burden representations, alternative formats, and downloadable content. [7] The guide belongs to a teaching context, not to publishing. Its relevance is architectural rather than prescriptive: participation can be offered through more than one temporal route, and each route makes different demands on the participant.
Android’s official offline-first guidance offers a similarly limited technical distinction. It describes an offline-first application as one able to perform all or a critical subset of core functions without network access. It also treats later synchronization and state consistency as active questions, rather than as a magical conclusion to an outage. [8] This does not make Android an editorial standard, and it does not decide the rules for two editors changing the same sentence. It helps isolate the difference between doing a critical local act and bringing that act into a current shared state.
That difference is the hinge of this paper. Offline capability is not one thing. A workflow may be able to support local drafting but not live review; local evidence gathering but not shared copyfitting; a queued correction but not a synchronized release decision. The correct teaching response is neither “everything must work offline” nor “the cloud is unavoidable.” It is to state which activity has which condition and what happens if that condition fails.
The Participation Condition Matrix
The Participation Condition Matrix is an original Wexley teaching instrument. It does not grade people, places, providers, or products. It does not certify accessibility. It does not recommend an architecture or determine a procurement choice. Its function is narrower and more useful: it makes the conditions of one workflow activity inspectable before an organization describes that activity as available.
| Matrix field | Reader asks | Proportionate output |
|---|---|---|
| 1. Activity | What exact creative or editorial action is being examined? | “Submit an attribution correction for review,” not “collaborate.” |
| 2. Participation moment | At what moment must the action count? | “Before final review begins.” |
| 3. Required state | Does the action need local work, current shared state, or a later verified handoff? | “Local correction now; shared review at handoff.” |
| 4. Condition stack | Which connection, device, energy, cost, account, media, skill, and state conditions matter here? | A named list rather than an assumed general access condition. |
| 5. Immediacy demand | What happens if a connection is not available at the stated moment? | “Preparation can continue; transfer cannot yet count as reviewed.” |
| 6. Local fallback | What can be retained or prepared without claiming completion? | “A dated correction note plus the revised local copy.” |
| 7. Handoff/synchronization question | What must be verified once shared connection returns? | “Which copy is current, and has the attribution note reached the editor?” |
| 8. Evidence status | What supports the condition statement? | “Workflow observed,” “policy inspected,” or “unverified.” |
| 9. Uncertainty signal | Who or what is blocked if the condition fails? | “The contributor cannot enter review at the required moment.” |
| 10. Escalation boundary | When does the issue belong to a more specific domain? | “Requires appropriate accessibility, security, contract, support, or coordination review.” |
A worked use makes the matrix more concrete. Imagine that Riverline Quarterly has two activities. The first is Mara’s attribution correction. The second is a synchronized final-read meeting in which several participants must compare a current layout and make a release decision.
| Field | Activity A: attribution correction | Activity B: synchronized final-read meeting |
|---|---|---|
| Critical activity | Deliver a corrected sentence, source note, and explanation for editorial review. | Participate in a joint check of the current release state. |
| Participation moment | Before a named editorial handoff. | During the scheduled shared check. |
| Required state | Local preparation can precede a verified later handoff. | A common, current view may be material to the activity itself. |
| Local fallback | Preserve the correction and rationale in a reviewable local artifact. | Prepare notes or questions, but local preparation does not replace the joint decision. |
| Handoff question | Can the editor identify the intended artifact and compare it against the current review copy? | Can all required participants access the same sufficiently current state at the relevant time? |
| Valid result | “Partially available pending documented handoff.” | “Connection-dependent; participation condition must be made explicit.” |
The worked use produces no winner. Instead, it produces a disciplined description. Activity A may permit a later handoff, but its eventual review remains necessary. Activity B may legitimately require connection at a particular moment, but the organization should recognize that requirement rather than treating it as invisible background. In both cases, the matrix can return unknown or requires evidence. That is a valid result. A workflow does not become inclusive because an instrument has been filled in.
The matrix also protects the boundary between neighboring Atlas papers. It does not ask whether a device can sustain a workload under battery, heat, storage, or operating-system constraints; that is the diagnostic work reserved for WEXLEY-WP-016. It does not create a team handoff rule; that action work belongs to WEXLEY-WP-023. It does not assess local-first preservation, conflict authority, privacy threats, or metadata quality. Its job is earlier: identify whether an activity has been made dependent on a condition that has not yet been named or evidenced.
What offline capacity does not solve
The phrase offline work can be comforting because it seems to promise independence. It should not. A local fallback does not provide a device. It does not make energy available. It does not resolve the cost of a service or the status of an account. It does not establish safety, privacy, or preservation. It does not make a shared copy current, settle a conflict, grant editorial authority, expand reader reach, or ensure that a later synchronization will succeed.
The strongest counterpoint to this paper is therefore not that intermittent connection does not matter. It is that connected systems can offer genuinely important capabilities: shared review, responsive support, distributed coordination, current publication information, and records that more than one person can inspect. The ITU framework’s interdependence is useful here. A solution that improves one dimension while weakening another is not automatically meaningful. [1] A lower-burden route may reduce a media demand while withholding needed visual information. A local artifact may preserve preparatory work while leaving a contributor outside a time-sensitive decision. A live meeting may support collective attention while excluding someone whose route cannot sustain the moment it requires.
The appropriate response is proportionality. Name the critical activity. Name the participation moment. Name the condition stack. Name the fallback. Name the state/handoff question. State what evidence exists and what remains unknown. Then, where the condition crosses into a technical, accessibility, security, contractual, financial, or editorial-governance question, move it to the appropriate specialized review rather than improvising a universal answer.
The participation threshold
A publishing workflow should not call itself accessible merely because it can be reached online. Nor should it call itself resilient merely because some local work can occur without connection. The more demanding and more useful standard is a participation threshold:
Before describing an activity as available, identify the activity, the moment at which it must count, the conditions it requires, the local fallback if any, the handoff or synchronization question, the evidence for each assertion, and the uncertainty that remains.
That threshold does not ask a small press, an educator, a product steward, or a contributor to solve every infrastructure problem. It asks them to stop hiding their own requirements behind a single word: access. The contribution of offline capacity may be modest but real. It can permit a contributor to prepare a correction, retain evidence, or continue a limited act until connection returns. Its limits may be equally real. The shared editorial record may still need a later verification, and some decisions may still require a current common state.
The teaching problem is therefore not whether to choose online or offline publishing. It is whether a workflow can see the conditions it asks other people to satisfy. When those conditions are made visible, a team can document a capability, acknowledge a narrow route, identify a block, create a proportionate fallback, or admit that it lacks the evidence to call the work reliably available. Each is more responsible than treating nominal connection as the same thing as participation.