Journalistic or Web Article Process

Canonical internal record: SOP-154 v1.0. Digital Sanctum owns and maintains this process. The accountable publisher records each application’s reviewers and release owner.

Adoption: Effective as an internal SOP only upon the publisher's attributable approval of this exact version. The controlling decision and current canonical version are retained in Core. Public mirror release is separate.

Purpose

Publish timely, useful reporting and explanatory web articles with traceable facts, clear uncertainty, fair treatment and accountable review. Readers must be able to distinguish the event, our interpretation and our commercial interest.

Scope

Use for news analysis, explainers, practical guides, interviews, opinion and commercial commentary. Label the chosen genre. Use the Academic & Research Article Process where the principal claim depends on original experiments or systematic research; link such research rather than presenting an unplanned investigation as a scientific study.

Apply existing Core article governance, governed publication/evidence requirements and the repository article-publishing procedure. This process supplies no authority for outreach, infrastructure changes, intrusive testing, policy adoption or public release. AI assistance is permitted within the commissioned information boundary and must be disclosed where substantive.

Prerequisites

• A commissioned brief, intended audience and destination, related Core ticket, scope and accountable publisher.
• An author/researcher, independent fact/technical reviewer, editor and release/maintenance owner. Neither accepting reviewer may have authored or materially co-authored the candidate. Record role combinations and conflicts. One qualified non-author reviewer may supply both technical and editorial verdicts only where applicable governance permits and the publisher explicitly records that combination; distinct native house requirements cannot be combined. AI reviews are advisory and cannot satisfy required human acceptance or an owner decision; identify them honestly without implying human or accredited review.
• Current destination capabilities, repository guidance and any subject-specific requirements; lawful access and rights to the proposed sources/media.
• A claim/source ledger, research log, draft/review history and correction log. Retain private evidence separately from reader-facing material.

Procedure

Phase 1: Commission the angle

1. State the reader's question, why it matters, genre and proposed angle. Decide what action or understanding the article should support.
2. Define coverage dates and timezone, scope, exclusions, delivery priorities and available resources with the publisher. Do not infer deadlines, authority or budgets.
3. Search existing content and guidance. Reuse or update substantial overlaps; distinguish a new event from a new report about an older event. Record commercial interests and potential conflicts before choosing comparisons.

Gate: an accepted brief identifies the audience, question, genre, destination and evidence needed. Output: commission and outline questions.

Phase 2: Research and build the claim ledger

1. Use search/news feeds for discovery. Read relevant original advisories, research, documents, datasets or statements in full enough to assess the claim and its qualifications. A snippet, failed fetch or truncated excerpt does not establish complete reading.
2. Record source URL/identity, author/publisher, publication/update and event dates, access time, exact supporting section and limitations. Retain lawful snapshots and hashes where useful. A status 200 response with an error/challenge body is not a successful source acquisition.
3. For each material claim, record proposed wording, evidence, confidence, factual/interpretive/commercial classification, uncertainty, reviewer and disposition. Corroborate contested or consequential claims independently where possible; syndication and copied reports are not independent confirmation.
4. Seek and read affected parties' existing responses. Distinguish researcher, vendor and independent observations. Any direct contact or external request needs separate authority and a recorded response deadline if commissioned; do not invent outreach or a declined response.
5. Protect private information, source identities where applicable, embargoes and publication rights. Attribute quotations accurately and proportionately; linked attribution does not permit unrestricted copying.

Gate: evidence supports the planned story or the angle is narrowed. Missing material evidence blocks stronger claims. Output: dated research log and claim ledger.

Phase 3: Verify chronology, scope and impact

1. Separate discovery, private report, disclosure, patch, exploitation and later coverage. Preserve exact source timezone, UTC conversion and the reader's date where material. Date-only sources remain date-only; do not invent a midnight timestamp.
2. For security coverage, distinguish a vulnerability, lab demonstration, attempted attack, confirmed compromise and speculative consequence. Verify product/implementation, tested versions, researcher-claimed affected range, vendor-confirmed affected range, configuration, prerequisites and fixed release separately from original evidence.
3. Classify AI involvement explicitly: assisted discovery/validation, exploit development, an AI product being affected, demonstrated attacker use, or broader commentary. An incident in the technology sector is not automatically an AI event. Product association is not proof of AI discovery or attack automation.
4. Map consequences to the affected component and reachable path. LAMP, WordPress, a PHP runtime, a database, a CMS admin and a server's SSH access are different boundaries. Evidence that an attack path is absent does not establish universal security.
5. Reconcile conflicts against original records. If unresolved, state each supported fact, identify the unknown, and narrow, hold or omit the disputed claim. Do not choose the date that best fits a news angle. Escalate serious allegations with unresolved factual disagreement to the editor/publisher; use attribution, narrowing, holding or omission without inventing outreach.

Gate: event identities, chronology, applicability and impact language are defensible. Output: fact-check and include/hold/exclude decisions.

Phase 4: Outline and draft

1. Agree the headline, summary and section order from the evidence. Lead with the reader's question and meaningful findings; keep qualifications beside the claims they limit.
2. Write clear explanations and supported practical actions. Attribute recommendations to their authoritative source and record an as-of date for fast-changing advice. Do not present a general article as a diagnosis of an uninspected client system.
3. Support comparisons and migration/case-study claims with actual records, deployment boundaries and permission for client examples. Disclose Digital Sanctum's commercial interest. Avoid immunity, universal superiority and measured-outcome claims without matching evidence.
4. Assess useful visual communication. Use an evidence-based timeline, architecture diagram or comparison table where it helps, or record why text suffices. Product showcases need authentic representative experience media or a scoped exception, safe data, rights, accessible alternatives and a refresh owner.
5. Prepare meaningful headings, link text, citations, byline, substantive AI-use disclosure, correction contact and metadata. Reuse the established article layout, contents/progress/series components and styles; preserve version history.

Gate: complete draft and source/claim package exist. Output: exact source/render candidate with stable version/hash.

Phase 5: Independent review

1. The fact/technical reviewer reads the complete candidate and material original evidence, checking dates, scope, quotations, numerical claims, causal/AI attribution, practical advice and omissions. Record reviewer identity, method and limits.
2. The editor checks genre/angle, fairness, clarity, citations, rights/privacy, conflicts and AI-use disclosure, brand and accessibility. Verify that news and commercial commentary are distinguishable.
3. Record findings, dissent and responses. Correct material errors and reduce unsupported claims. Any material change creates a new candidate and renews affected reviews; an accepted predecessor does not approve changed bytes.

Gate: independent fact/technical and editorial verdicts accept the same exact candidate, with no unresolved material defect. Output: review ledger and revised candidate.

Phase 6: Prepare and authorise release

1. Distinguish permission to make proposed SOP text internally visible in Core, adoption of that exact process version, and permission for a public mirror or resulting article release. Record each scope and effective state separately; one receipt covers several only when it explicitly names each. Adoption of this process does not approve any resulting article. Confirm the destination's live content/review/release contract. A CMS collection accepting a draft does not establish publication support for a new route or content type. Resolve capability gaps through their proper project and review, not a side channel.
2. Verify responsive and keyboard reading, contents/progress/series behaviour where applicable, link/citation targets, media/figure alternatives, metadata/canonical/indexability and intended discovery. Use the existing build and applicable validators; a build pass alone is insufficient interaction evidence.
3. Freeze the complete candidate, reviews and evidence. Prepare the release order, recovery snapshot and post-release checks. Refresh fast-moving facts immediately before release and identify the exact sources refreshed and effects on claims/reviews; material changes renew relevant reviews.
4. Obtain the exact authorised publication decision through the current controls, including required native independent reviews. An approved goal, ticket, draft or source merge is not a publication receipt.

Gate: release prerequisites and exact human decision are satisfied. Output: immutable release package and decision receipt.

Phase 7: Publish and verify live

The authorised publisher releases in dependency order so new links resolve. Verify the live revision/content, links, accessibility/reading behaviour, disclosures, metadata and discovery placement. Record URLs, times, environment, observers, results and limitations. Reconcile ambiguous writes/publications before another attempt. Distinguish source saved, committed, pushed, deployed and independently verified live.

Gate: the intended audience can access the accepted content and live checks are recorded. Output: publication/verification record.

Phase 8: Monitor and correct

At release, assign an owner and proportionate review window/triggers for advisory changes, new evidence, reader corrections and broken links. Do not create recurring automation without authority. Correct material errors visibly with date/reason and affected claims; identify significant updates to fast-moving coverage. Escalate fabricated evidence, central unsupported allegations or substantial unreliability to the accountable editor/publisher, who decides correction, a visible notice of concern, or withdrawal/retraction under applicable policy. Preserve the historical record with a dated explanation, subject to lawful privacy/safety constraints, and assess affected timelines and derivative articles as separately controlled changes. Preserve earlier evidence and review history. Review the process after delivery and create follow-on work for unresolved gaps.

Urgent-update path

The publisher may commission a short, explicitly provisional advisory when timeliness matters. It still requires verified primary facts, bounded applicability, fact/technical and editorial checks, accurate uncertainty and the existing release decision. Record omitted depth and a named follow-up owner/window. An urgency label never relaxes permissions, factual integrity, source rights or the live publication controls. Hold an unsupported claim even if the rest of the advisory can publish.

Rollback / Recovery

If evidence fails, retain the error and narrow/hold the affected claim. If acquisition returns partial or changed bytes, reacquire through an allowed read path and renew dependent checks. If a write's outcome is unknown, reconcile the exact durable operation before retrying. If a defective article is public, use the approved correction, containment or withdrawal path, retain history and verify the resulting public state; cached copies may remain available. Correcting one article must not silently change unrelated timelines or process standards.

Verification

• [ ] Commission, genre, audience, scope and accountable roles are recorded.
• [ ] Material claims have read, attributable evidence and explicit uncertainty/conflicts.
• [ ] Event/report/patch dates, implementations, versions and AI involvement are distinguished.
• [ ] Comparisons and client/migration claims match records, scope and publication permissions.
• [ ] Independent exact-version fact/technical and editorial verdicts are complete.
• [ ] Rights, privacy, disclosures, accessibility, reading interactions and discovery are checked.
• [ ] Authorised release, live verification, recovery and maintenance records exist.

Worked example

For a security explainer, build separate records for PHP2Shell, Tailworm/Tailscale SSH and an OpenCode MCP vulnerability. Check each date and AI connection independently. A researcher lab result is labelled as such; a vendor's uncertainty is retained. A migration comparison maps the public PHP request path, static website, CMS/admin, host and old hosting separately. A disputed disclosure date can remain held while verified facts support a carefully dated explainer. This example describes the workflow; the incident research record supplies the facts.

Related

Maintain native Core relationships to existing article governance, governed publication/evidence and the companion academic process. Apply docs/article-publishing.md for this repository. Core identity/relationships and public mirror version are verified at registration; this draft does not claim those edges already exist.

Explore the standards

Standards index · Academic & Research process · Journalistic or Web process · UX/UI proposal.