Skip to content

ROADMAP.md

Latest commit

 

History

History
70 lines (61 loc) · 3.66 KB

ROADMAP.md

File metadata and controls

70 lines (61 loc) · 3.66 KB
Raw

Falsiflow Roadmap

This roadmap keeps the public direction narrow: make evidence-gated claims easy to try, hard to misuse, and straightforward to verify before publication.

Now

  • Keep quickstart, doctor, claim-check, adoption-check, and release-check reliable as the first-run path.
  • Maintain bundled starter templates for coatings, neural materials, vendor handoffs, and wetware support hardware.
  • Keep template packaging, lockfiles, attestations, policies, releases, and installs release-checked.
  • Preserve the responsible-use boundary in CLI output, docs, launch copy, and issue templates.
  • Keep built-in adapter profiles for generic wide CSV, vendor measurement, instrument export, and plate-reader imports documented and regression-tested.
  • Keep the browser workbench useful for non-CLI reviewers by surfacing the ready/blocked review flow, evidence lineage, repair checklist, and linked artifacts from the local app.
  • Keep report-level artifact indexes in claim_check.md, bundle verification, release-check, and template release verification reports so reviewers can follow source, bundle, and template-release evidence without directory hunting.
  • Keep public casebook reviewer replay artifacts for Bash and PowerShell so positive demos and placeholder blocked-path fixtures can be reproduced without hand-copying commands from prose.
  • Keep launch metrics artifacts in the public launch kit so GitHub traffic, referrers, stars, forks, clones, demo visits, install/download signals, and repeated questions are reviewed after launch instead of guessed from memory.
  • Keep a public release evidence ledger in the publish kit so repo, demo, PyPI, pipx, Windows, Scorecard, release-check, casebook replay, and launch metrics evidence are reviewed from one place.
  • Keep a public release rehearsal in the publish kit so preflight commands, expected artifacts, success signals, and strict external stop conditions are reviewed before public announcements.
  • Use the Falsiflow External Evidence workflow to collect hosted demo, PyPI package URL, checkout-based pipx, public-package pipx, and Windows smoke evidence after public launch.
  • Keep a small public queue of good first issue, help wanted, template, and launch-readiness issues so new contributors can improve docs, demo proof, examples, and starter gates without changing the core claim contract.

Next

  • Add additional import profiles only when their column mapping, provenance behavior, and coverage checks can be documented and tested.
  • Expand release evidence around PyPI, GitHub Pages, and cross-platform smoke artifacts once the public repository is live.
  • Expand the RAG quality gate proposal into a bundled starter template once the initial PyPI and external-evidence loop is closed.
  • Add more opinionated downstream examples for AI eval and product-metric repositories after the reusable action is pinned to a public release tag.

Later

  • Support template registries maintained by external teams.
  • Add optional signed release evidence beyond local HMAC attestations.
  • Add more domain templates only when they include clear claims, evidence contracts, source-file examples, and responsible-use boundaries.
  • Explore lightweight integrations with ELN/LIMS exports, CI artifacts, and hosted docs without turning Falsiflow into an orchestrator or database.

Not Planned

  • Arbitrary code execution inside project configs.
  • Replacing ELN/LIMS, laboratory notebooks, regulatory systems, or expert review.
  • Treating claim_ready as scientific proof, safety proof, clinical evidence, or commercial approval.
  • Hidden cloud upload or hosted data processing as a default workflow.