Rik Bose @infiniterik

Mission AI publishing workflow

The public site is https://infiniterik.github.io/mission-ai/. Files live under mission-ai/ on the master branch of infiniterik/infiniterik.github.io.

Make scenarios

  • Read coverage history: reads the current branch commit, then reads the ledger at that exact commit. Returns head_sha and decoded ledger_json.
  • Publish edition and ledger: serializes the prepared inputs and commits the edition, complete ledger, and coverage context together using GitHub’s createCommitOnBranch mutation and expectedHeadOid.

The writer is inactive pending a GitHub connection with public repository write access. The current Make connection is read-only. Scenarios use standard Make modules; no paid Code module, data store, or additional service is required. The initial pilot was published through the connected GitHub app.

Publish another edition

  1. Run Read coverage history before research. Use its ledger to check the prior 7 and 30 days, recent lead themes, source-family concentration, canonical links, and story identifiers. data/context.json is also a convenient snapshot as of the latest issue date.
  2. Build an edition JSON using seed-edition.json as an example. Preserve stable story IDs across reports about the same development. Group sources by their original institution, not by the hosting platform. Save complete HTML and the structured evidence together in the edition’s html, articles, sources, stories, and coverage fields. Every external HTML citation must appear in coverage; paper HTML/PDF/abstract aliases normalize to one paper.
  3. Run node prepare.js ledger.json edition.json HEAD_SHA make-inputs.json, using the ledger and head from step 1. Preparation is a local Node step, not code executed by Make. It validates references, checks variety, retains history, calculates the 7/30-day context, and produces the five Make input values. No dependencies are required beyond Node 22 or newer.
  4. If the result is needs_revision, inspect the reasons and revise. A recorded variety_override_reason can waive diversity targets for an editorial reason, including urgent security coverage; it cannot waive data-integrity errors. Context is allowed but does not count as a new story. An existing story marked update requires a material-change note plus a new source, an explicit artifact_version, or an urgent_reason. Keep actual identifiers such as CVE and arXiv IDs stable; semantic grouping still requires editorial judgment.
  5. Run Publish edition and ledger with the generated five inputs. A returned commit means the write succeeded; check the GitHub Pages build afterward. A stale-head failure means another edit landed: rerun step 1 and prepare again. Never force a ref update.

Identical edition replay returns already_recorded during preparation. Changed content cannot reuse an existing edition ID; publish a dated correction ID. The Make writer expects prepared data and does not independently rerun the editorial validator. Its optimistic commit check prevents replaying the same prepared write or overwriting concurrent edits.

Variety policy

Defaults: 60% new stories; at least three source families; flag a family above 40% of unique cited articles; cover agentic AI, cybersecurity, and research; avoid repeating lead themes from the prior three editions. These are editorial targets, with visible override reasons. The 7/30-day windows count distinct story selections per theme and editions per source family, not raw link occurrences. Older sources are labeled as context. Related reporting is not assumed independent.

Data and operational limits

data/ledger.json is the versioned system of record: normalized articles, sources/families, story identifiers, theme catalog, per-edition coverage, dates, novelty/update notes, and payload hashes. Git commits retain the audit history. Full source articles are not mirrored. The pilot includes 15 canonical source records, ten source families, and eight stories.

The site fetches the ledger on load. Failure leaves the sample briefing accessible and displays an error. Search and filters run entirely in the browser. GitHub’s Contents API limits apply: split the ledger by year before it reaches 1 MB (the reader uses its base64 content response). Preparation and reader runs use the full history; long-term archiving should preserve a compact cross-year identity index.

Daily research collection, AI drafting, email delivery, and scheduling have not been activated. These two on-demand scenarios provide the coverage memory and publishing steps for that future pipeline.