Task 1 (Data Structure) Task 2 (Terminology standardization) Task 3 (impact of change) Mission 1 (Decision Making) Mission 2 (Exception Scenario) 📊 View Summary ← Classroom
Day 3 Mission 01 Decision logging

Mission 01. Design Decision Log

Automatically creates a standard Design Decision Log (Why) report that records database normalization methods and architecture decisions.

Mission 1 Design Decision Recording Practice Guide

📥 Practice Input

  • • tech-design-meeting.md (meeting conversation transcript)

💾 Practice output (Output)

  • • design-decision-log.md (Decision record document)

1. Story and practice background

As time passes, new developers join, look at the source code, and have questions. “Why did you create a separate history accumulation table by only changing the reservation status value instead of dividing the reservation cancellation history table 1:1 from the main reservation table? It would have been easier to just add a column.”

The reason was a thoughtful decision made by senior engineers and planners 6 months ago to meet security/audit requirements and optimize the performance of daily reservation cancellation statistics. However, because there was no documentation to record this, the new developer was able to overturn the design at will, causing a failure that completely paralyzed the previous cancellation statistics dashboard.

In this mission, the background of data normalization and architecture decision made in the technical design stage was standardized using Codex. Design Decision Log Learn how to safely manage a system's historical assets and design rationale (why) by documenting them.

2. Learning objectives

  • Normalization and database structure design decisions can be accurately extracted from meeting minutes.
  • Decision items, background reasons, review of alternatives, approvers, and possibility of future changes can be specified.
  • By recording the history (why) of design decisions, you can prevent duplicate meetings and mistakes by new team members.

🛠️Practical guide to follow along

  1. Create file for practice: Click the download button below tech-design-meeting.md file automation/ Save it within the folder.
  2. Codex logging delegation: Build by sending the **Codex request prompt** below to the Codex Client prompt input window.
  3. log check: In the printed report, review whether the decision ID (DEC-003), decision background, review alternative (reason for rejection), and approval entity are structured correctly.

Download practice materials

Codex request prompt

Mission 01 Prompt
Please extract normalization and database structure design decisions from the meeting and create a Design Decision Log that includes decision items, background reasons, alternatives reviewed, approvers, and possible future changes.

4. Example results

Codex documents the architectural conclusions and the basis for compromise in the conversation history as follows.

[Decision ID: DEC-003]
• decision: Reservation cancellation history is designed to be separated 1:N into a separate Reservation_Histories table instead of accumulating it directly in the Reservations table.
• Decision background (Why): Prevents write lock bottlenecks on the main table due to frequent reservation status changes and meets history tracking requirements by date and agent.
• review alternatives: Directly add canceled_at, cancel_reason to the Reservations table (dismissal: cannot record multiple cancellation history and risk of table bloat)
• approval entity: PM and Lead Engineer (Approver: Dev_Lead)
• Possible changes in the future: When large-scale traffic occurs, history may be transferred to NoSQL Document DB.