# VedaBase milestone foundation

**Status:** Foundational planning material for review. This folder is not the
approved company roadmap, a delivery commitment, an investor presentation, or
a source of implementation/corpus truth.

## Purpose

This area reconstructs reusable milestone building blocks for an 18-month
planning conversation. It connects repository evidence to product outcomes,
capabilities, achieved-state milestone candidates, acceptance evidence, and the
decisions that evidence could enable.

The canonical current status remains [`../CURRENT.md`](../CURRENT.md). Accepted
architecture decisions remain in [`../12-decisions.md`](../12-decisions.md).
Checked code, exact artifacts, manifests, hashes, and fresh runtime evidence
continue to outrank this planning synthesis.

## Evidence labels

- **Confirmed** — explicitly supported by a current source or checked
  implementation evidence. Code presence proves implementation shape only, not
  product completion, runtime quality, adoption, or release readiness.
- **Inferred** — derived from multiple repository signals but not stated as a
  decision.
- **Recommended** — planning, sequencing, product, UX, technical, or
  measurement judgment introduced by this synthesis.
- **Open** — unresolved, contradictory, or insufficiently supported.

Confidence is shown as High, Medium, or Low where it helps readers distinguish
stable direction from fragile planning assumptions.

## Navigation

1. [`00-source-map.md`](./00-source-map.md) — authority, currentness, coverage,
   and conflicts of inspected sources.
2. [`01-confirmed-assumed-recommended-open.md`](./01-confirmed-assumed-recommended-open.md)
   — evidence ledger, assumptions, gaps, and unresolved choices.
3. [`02-product-outcomes-and-workstreams.md`](./02-product-outcomes-and-workstreams.md)
   — product vision, users/jobs, desired outcomes, initiatives, and continuing
   workstreams.
4. [`03-capability-traceability-matrix.md`](./03-capability-traceability-matrix.md)
   — complete material capability inventory and `Source -> Capability ->
   Milestone -> Strategic outcome` chain.
5. [`04-master-milestone-catalog.md`](./04-master-milestone-catalog.md) —
   executive index of major candidate milestones.
6. [`05-dependencies-and-sequencing.md`](./05-dependencies-and-sequencing.md) —
   prerequisites, parallel lanes, bottlenecks, and sequence-sensitive choices.
7. [`06-18-month-candidate-roadmap.md`](./06-18-month-candidate-roadmap.md) —
   rolling-wave planning recommendation, alternatives, and conditional work.
8. [`07-platform-language-intelligence-matrix.md`](./07-platform-language-intelligence-matrix.md)
   — cross-cutting platform, corpus, language, intelligence, cloud, and release
   view.
9. [`08-measurement-and-acceptance.md`](./08-measurement-and-acceptance.md) —
   source-defined and recommended evidence without invented targets.
10. [`09-roadmap-deck-building-blocks.md`](./09-roadmap-deck-building-blocks.md)
    — presentation-ready raw material, not a finished deck.
11. [`10-open-decisions-and-conflicts.md`](./10-open-decisions-and-conflicts.md)
    — decisions ranked by roadmap impact and explicit source conflicts.
12. [`catalog/`](./catalog/) — one parseable, reusable card per major milestone.

## Review and conversion into an approved roadmap

Before turning this foundation into a roadmap or deck:

1. Reconcile each source conflict and record the decision in its authorized
   source, usually an ADR, product decision, artifact authorization, or release
   record—not in this folder alone.
2. Confirm the release population, product scope, owners, capacity, funding,
   rights, and thresholds that the repository does not currently establish.
3. Test the near-term user journeys with representative users and define the
   minimum coherent macOS release experience.
4. Re-estimate sequencing against actual team capacity. No staffing plan or
   delivery-rate evidence was found that could support a commitment calendar.
5. Move only accepted milestones into the actual roadmap. Keep rejected,
   deferred, and conditional candidates visible in the decision history.
6. Build the milestone deck from [`09-roadmap-deck-building-blocks.md`](./09-roadmap-deck-building-blocks.md)
   only after leadership has reviewed the evidence classifications and open
   decisions.

## Updating this catalog

- Preserve stable milestone and capability IDs. Mark a card superseded instead
  of silently reusing its ID for a different achieved state.
- Update source references and evidence labels when code, artifacts, ADRs, or
  decisions change; do not copy a new status here without updating the
  authoritative source first.
- Separate a deliverable from its milestone. A database, app build, document,
  or service is a deliverable until evidence establishes the achieved product
  state.
- Record threshold changes in the owning evaluation/release specification.
  Use `TBD` here until the authorized owner decides them.
- Revisit dependencies, horizon, confidence, and affected decisions after each
  material product or architecture decision.
- Run `python3 scripts/check_documentation_truth.py` and the validation checks
  described in this folder before using it as deck input.

## Deliberate boundaries

This foundation does not:

- promote or mutate a corpus candidate;
- authorize a full-corpus build, vector build, release, deployment, external
  transmission, pricing publication, or commercial launch;
- infer scholarly, BBT, ISKCON, institutional, product-owner, or leadership
  approval;
- assume iOS, Android, additional-language editions, cloud collaboration,
  managed Agent Cloud, or narration fit inside 18 months;
- replace the active roadmap, ADRs, current-state document, product specs, or
  exact implementation evidence.