AI Timeline Entry Process

Canonical internal record: SOP-157 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. This process grants no release, recurring monitoring or external outreach authority.

Purpose

Create consistent, useful and traceable milestones on Digital Sanctum's AI Timeline. Each milestone identifies a dated event, explains what practical choice it changed, cites evidence and states important limits. A timeline entry is a short editorial record; it does not require a separate article for every event.

Scope

Use this process for model and product releases, meaningful availability changes, research results, licence and cost changes, security incidents and other evidenced events within the timeline's commissioned scope. Use Journalistic or Web Article Process, for sourcing, attribution, factual/editorial review and corrections. Use Academic & Research Article Process, when our principal claim depends on original experiments or a systematic research method. A vendor benchmark mentioned in a release entry is an attributed source claim, not our original experiment.

Apply Website Content Architecture Standard, to the timeline's discovery links and any supporting article, and Governed Publication and Evidence for AI Workforce Outputs to governed publication and evidence. Article Standards — Naming, Linking, and Lifecycle Rules governs the internal Core knowledge record. Retrieve current versions before delivery; these references do not freeze future versions or adopt proposed guidance by association.

Prerequisites

• A commissioned reader question, scope, accountable publisher, destination and related Core ticket.
• Access to current process versions, typed destination, original evidence and lawful source materials.
• Named author, applicable non-author reviewers and release/corrections owner; retain the exact candidate and decisions.
• A supported publication route, build/browser tooling and a fresh preservation baseline for the intended release.

Roles and retained records

The publisher commissions the scope, records applicable review roles, decides inclusion and release, and appoints corrections ownership. The author researches and drafts. Non-author fact/technical and editorial reviewers assess the exact candidate and material sources under the applicable parent process. One qualified non-author human may combine those two verdicts only where governance allows and the publisher records the combination and conflicts. AI assessments are advisory and do not substitute for required human verdicts. The release operator implements the reviewed change and verifies public state.

Retain the Core ticket, brief, source/claim ledger, date reasoning, include/hold/exclude disposition, draft identity, review findings and decisions, build/browser evidence, release and recovery receipts, and correction history. Keep private review material outside public output. Record actual verification and limits; do not infer approval or a complete audit from a green build.

Entry contract

Use the current destination's typed record and validator. Map these editorial fields to that record rather than inventing a second source of truth.

The website currently uses categories including Capability, Access, Retirement, Licence, Cost, Place, Control, Lock-in, Trust and Foundation. Use the live vocabulary and its meanings; changing a category set is a separate reviewed schema/design change. Record optional specialised evidence, such as licensing or release reception, when it is part of the claim.

Procedure

A gate is a readiness condition. Reuse the applicable parent process’s decisions; do not add a separate approval for every checklist item.

Phase 1: Commission and check overlap

State the reader's need, candidate event, scope, intended route and accountable publisher on a related Core ticket. Search current published, draft, held and excluded entries for duplicates or revisions. A new report about an old event does not automatically make a new milestone.

Read the existing process versions, source schema and timeline interaction conventions. Establish which release route is supported now. A native timeline dry run is not public publication, and its receipts or coverage claims cannot be invented from repository HTML. Where the commissioned destination is the website and the native publication capability is unavailable, record the supported website route and its evidence boundaries. Honour any additional retention requirements in the commission; resolve a conflicting prerequisite before release.

Gate: the commission identifies the reader, scope, accountable publisher and supported destination; unresolved route conflicts are retained before release. Output: brief, duplicate disposition, process versions and publication-route record. Missing information may narrow or hold the entry rather than block unrelated process work.

Phase 2: Acquire evidence and establish the event

Prefer the original publisher's announcement, release notes, model card, paper, repository tag or advisory for event identity and dates. Read the actual supporting material; search snippets, an empty page, a challenge page or an HTTP 200 error document do not establish successful acquisition. Record URL, publisher/author, dates, check time, supporting passage or section and limitations. Preserve lawful snapshots or hashes where useful.

Distinguish model from product, API from ChatGPT/Codex or another application, and a named checkpoint from a moving alias. Announcement, rollout, general availability, weight release, pricing-effective date and retirement deadline are different events. Date-only evidence stays date-only; do not invent midnight timestamps. Record source timezone and conversions when they affect chronology. Reconcile material conflicts or state the supported facts and hold the stronger claim.

Attribute performance, cost and capability claims. Separate vendor claims, independent assessments, community observations and Digital Sanctum measurements; retain their versions and methods where material. A third-party provider listing does not alone establish first-party release or exact model provenance. Do not imply Australian eligibility, client-data suitability or blanket availability from a global announcement. For incidents, verify the claimed AI connection under Journalistic or Web Article Process rather than assuming any technology-security story is an AI event.

Gate: original evidence supports the proposed event and date, or the stronger claim is narrowed or held. Output: source/claim ledger, date basis and include/hold/exclude recommendation. Publication requires adequate support for the actual claim, not a fixed arbitrary number of sources. Preserve justified holds and exclusions with reasons.

Phase 3: Draft the entry and its relationships

Complete the entry contract in the existing record. Use a factual title and a summary that describes the event rather than promoting the issuer. Explain a bounded practical implication and keep necessary qualifications beside it. Do not treat a benchmark score as a general ranking or promise a business outcome from a release announcement. Disclose substantive AI assistance in the entry or clearly associated collection context; retain author and reviewer roles in the delivery record.

Classify a genuinely new event separately from a correction, later effective date or access revision to an existing event. Preserve the original event's date and identity when revising it; record what changed and why. Check chronology and earlier content before selecting the default milestone or changing timeline-wide counts or coverage statements.

Link an existing public explainer where it helps. Commission a separate article only when the reader needs more explanation or original evidence. Choose its canonical route and breadcrumb through Website Content Architecture Standard; a timeline link alone does not place that article under a new URL family. Add guide-directory navigation under the existing element-cycle convention; do not duplicate a full essay in the timeline or create another directory card for every cycle.

Gate: the mapped draft is complete, distinct from overlapping events and traceable to its sources. Output: complete draft record, source ledger and rendered preview bound to a revision. Original research or a new companion article follows its own applicable commission and acceptance.

Phase 4: Review and verify the exact candidate

Apply the required factual/technical and editorial reviews from the parent process to the actual entry, sources and rendered context. Check event/model identity, date basis, release stage, practical category, quote/claim attribution, restrictions, AI relevance, uncertainty and commercial conflicts. Record each verdict, findings and disposition on the exact candidate. Material content changes renew affected review; routine technical preparation must not silently alter accepted copy.

Check unique IDs, valid source links, category vocabulary, chronology, counts, selection/deep links, chart/explorer interaction, filters, pagination and onward links affected by the change. Verify desktop and narrow-screen reading, keyboard/focus behaviour and essential content without JavaScript. Check applicable reduced-motion, zoom and overflow behaviour for changed interaction or presentation. Preserve earlier entries, protected content and unrelated outputs. Record not-tested and not-applicable cases with reasons; neither screenshots nor automation establish full accessibility conformance.

Gate: required non-author verdicts accept the same candidate, affected checks pass and no material defect remains in the proposed published claim. Output: version-bound review dispositions and verification evidence, including untested limits.

Phase 5: Release and verify public state

Prepare a bounded release scope with source/render identity, intended changed outputs, live predecessor, preservation checks and proportionate recovery plan. Obtain the required publisher decision on that scope. Reconcile current source, runtime capability, live files, configuration and other workstreams' release fences immediately before the effect. Stop on material drift and prepare a successor rather than overwriting another release.

Use the supported route and durable idempotency/receipt controls. If a mutation or deployment result is uncertain, inspect its durable status and actual state before retrying. Retain owned locks and recovery evidence until reconciled; do not remove another release's lock. A preview, merged PR or dry run is not a public release receipt.

Read back the live entry, event date, title, summary, sources and limits. Exercise the intended timeline selection or fragment, relevant filters and onward links; verify public discovery/search where intended, site health and preservation of unrelated outputs. Record the actual revision and release time, results, failures and any recovery. Do not claim native event-ledger acceptance or coverage from a website-only release.

Gate: the exact publisher release decision and current route controls precede effect; successful delivery requires verified public state. Output: live publication evidence or an explicitly incomplete/recovered release, retained on the ticket. Complete delivery records only after the required evidence exists.

Phase 6: Maintain and evaluate

Assign corrections ownership and proportionate review triggers: new official evidence, changed availability, revised source claims, broken links or reader corrections. Do not schedule recurring checks or outreach without authority. Preserve original event identity and significant revision history; correct material errors visibly where needed and assess affected related content separately.

For the first pilot and material process changes, compare actual work against every step and gate. Record pass/fail/not applicable/not tested with evidence, friction, deviations and limits. One successful model-release entry does not demonstrate that the process is proven for security incidents, licence changes or every future milestone. Review and adopt substantive process amendments before publishing a corresponding public revision.

Gate: corrections ownership and actual evaluation evidence are retained; substantive amendments follow review/adoption before public revision. Output: correction owner/triggers, pilot findings and any reviewed amendment. Close tickets, milestones and project only when their commissioned deliverables and child evidence are complete.

Reusable entry worksheet

• Event and stable ID:
• Exact issuer, model/product/checkpoint and access surface:
• Reader question and practical change:
• Existing/related entry and new/revision/hold decision:
• Event date, precision, timezone and date basis:
• Source URL, publisher, publication/update date and actual checked time:
• Supporting location and claims supported; acquisition/test limits:
• Release-state label and primary/secondary decision classification:
• Proposed title, summary and practical implication:
• Attributed vendor, external and local claims:
• Access/applicability limits and unresolved questions:
• Public onward links and canonical content relationships:
• Exact candidate identity, reviewers/verdicts and outstanding findings:
• Build and browser verification; untested conditions:
• Publication route, required decisions, release/recovery evidence:
• Live verification, corrections owner and triggers:

Rollback / Recovery

Before release, retain the verified predecessor, exact release scope and route-specific recovery procedure. On failed or uncertain publication, inspect the durable receipt, current public state and release-fence ownership before retrying. Restore only the identified authorised release through its supported recovery procedure; preserve another workflow’s lock and evidence. Recheck restored content, source links, discovery and site health, and record the failure and recovery on the delivery ticket. A recovered predecessor is not successful publication of the proposed entry. Correct material editorial errors through a reviewed correction or successor, retaining significant history and affected decisions.

Explore the standards

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