Product OS is a local-first system for turning local source files, decisions, and work-in-flight into a durable product memory that can support prioritization, decomposition, validation, explanation, and curated outputs like weekly updates.
The Product OS is a composed system. Each layer narrows ambiguity and increases judgment quality. It is designed so that raw context does not directly generate polished artifacts without passing through memory and reasoning first.
Product OS is not a note archive. The memory layer is the real advantage because it preserves product reality in a form that later reasoning can trust. Signals are small, but promoted memory is durable and strategic.
The system currently uses `problem`, `initiative`, and `work_item` internally. User-facing reasoning and rendering translate those into `outcome`, `initiative`, and `bet` where useful.
Nothing durable should quietly mutate. The review layer is where the system proposes meaning and the human decides what becomes truth.
inputs -> signals -> review -> memory atomic context -> proposed meaning -> approved product reality
The reasoning stack exists so the system can decide, structure, test, and articulate product judgment without improvising a different logic each time.
Decide what matters now. Default tactical use is a ranked bet view, but the system can also reason at the initiative and outcome horizons.
Decide how to break a chosen object down. The system is lens-aware, so it can decompose by leverage points, behavior, structure, or a mixed frame when needed.
Check whether the chain is actually coherent enough to act on. Validation exists to stop the system from becoming fluent at weak product logic.
Translate the reasoning for yourself, a team, or leadership without changing the actual substance. Narrative is an adaptation layer, not a replacement for logic.
Renderers turn memory plus reasoning into usable artifacts. The rule is simple: outputs must be downstream of approved memory and explicit judgment, never a shortcut around them.
The first renderer is a curated weekly narrative. It favors connected outcome and initiative framing, uses timeframe-aware curation, and stores approved updates as continuity artifacts in `memory/weekly_updates/`.
Bet briefs, decision log entries, and later roadmap views all fit here. They should reuse the same connected chain rather than inventing a separate story per artifact.
A roadmap is a renderer, not a memory primitive. It should come after stronger sequencing, validation, and continuity, so it reflects real confidence instead of polished overstatement.
The local app is now the primary reading and review surface for the MVP. Home / Today now integrates review pressure, continuity, and next-action nudges.
cd /path/to/product-os uv run uvicorn productos.app.main:create_app --factory --reload
Then open http://localhost:8000 in the browser.
The next major layer is not more core logic. It is a better operating surface. The CLI is good at orchestration, but it is weak at review, comparison, approval, and polished reading. The interaction layer should solve that without replacing the engine.
A local workspace app with a workflow-first early emphasis and a persistent workspace shape over time.
Contexts like `job` and `asteroid-belt` should share methods, not a single blended graph. The app should always make the active context visible and isolate memory by default.
shared methodology
+ context-aware local workspace app
+ isolated context memory
contexts/job/*
contexts/asteroid-belt/*
Early on, the system needs help creating memory, so guided flows matter more than a dense dashboard.
As memory accumulates, browsing, continuity, comparison, and review become more valuable than simple action launching.
The UI should orchestrate the existing core engine, not fork business logic into a second hidden system.
The current CLI already covers the full local-first path from ingestion to reasoning and the first renderer.
uv run productos ingest path/to/file-or-folder --source-date 2026-03-24 uv run productos ingest path/to/folder --recursive --source-date 2026-03-24 uv run productos signals extract transcript-weekly-product-review-2026-03-20 uv run productos review generate transcript-weekly-product-review-2026-03-20 uv run productos review list
uv run productos reason prioritize --view bet uv run productos reason decompose --target-type initiative --target-id initiative-rewrite-onboarding-copy uv run productos reason validate --target-type bet --target-id work-item-ship-onboarding-copy-test uv run productos reason explain --target-type bet --target-id work-item-ship-onboarding-copy-test --audience exec --horizon full-chain --include-narrative
uv run productos render weekly-update --from 2026-03-16 --to 2026-03-22 uv run productos render weekly-update --last 7d uv run productos render weekly-update --this-week
Approved canonical memory is the default substrate. Raw artifacts are fallback material, not the first thing the system reasons over.
The renderer should never be the place where the real thinking first happens. Otherwise outputs become polished but unreliable.
Important conclusions should expose evidence, confidence, tradeoffs, and what would change the conclusion.
The v1 ecosystem is already real enough to test end-to-end on local artifacts. The current emphasis is on making memory and reasoning durable before expanding the output surface too aggressively.