What happened
The creator released PDDR Kit, an open-source record format covering Project, Product, and Process decisions. It separates decision_status (whether a decision was adopted) from delivery_status (how far implementation and validation have gone), and the current stable version is v0.2.1.
Why it matters
Splitting decision_status from delivery_status is meant to block the leap that something adopted is therefore code-complete or validated. That is a real working distinction: an adopted approach may not be in the code yet, and code may exist without a verified result.
What to watch
Whether teams resist adopting it because PDDR is not a work log — typos, routine dependency updates, and small refactorings are explicitly out of scope. The test is whether the one simple standard holds: would a future owner repeat the same debate without knowing the reason?
WHO IT HITSDevelopment teams using Git, Issue, PR, and chat histories will need to judge whether they want the pre-decision observations and post-decision verification tied together in one index, rather than scattered across those separate tools. The body argues the benefit is fastest recovery for the person who wrote the code weeks earlier.
Summaries like this, in your inbox every morning.
The article starts from a common frustration: Git records code history accurately, Issues hold the background, PRs hold the discussion, and chat logs hold the AI consultations, but each lives in a different place. Reconstructing why a feature was shelved or why an experiment was stopped becomes an archaeology project for the person who wrote it weeks earlier. The author first looked at ADR (Architecture Decision Record) and DDR (Design Decision Record), but found that the painful decisions were not limited to architecture. They reached into Project, Product, and Process, so PDDR widened its scope to those three areas while explicitly not replacing ADR or DDR.
The most pointed design choice is state separation. If decision_status and delivery_status are merged, the author notes, people start assuming adoption means implementation and code means validation. A second choice concerns AI: the Recorder Skill is told not to fill in reasons absent from the conversation, marking unclear history as unknown and unconfirmed human agreement as needs-confirmation. A third is scoping: PDDR is not a work diary, so typos and routine dependency updates are excluded to keep important decisions visible.
The kit is dogfooded on itself and on the sample pddr-greenfield-example and the tech-content repository behind this Zenn article. The stakes seem to hinge on whether teams accept that separation and scoping, since the body frames feedback on 'this is heavy' or 'this decision was not captured' as the next input it needs.
For example, today's edition would include:
AI-summarized, only the topics you pick: one digest a day via Email, LINE, or Slack.
Free · 30 seconds with Google · unsubscribe anytimeWhat is AIToday? →
Ask AI anything about this article. The AI reads this article, earlier AIToday articles, and Wikipedia, and cites its sources. Q&As are published on this page for other readers too.
