# INVEETAIRE
## DESIGN REVISION PACK

Version : 1.0

Status : Pending Review

Document Type : Design Revision Proposal

Created After :

- Product Discovery
- Product Vision
- PRD v1.1
- SAD v1.1
- DDD Conceptual v1.0
- DDD Logical v1.1
- Development Blueprint (DBP v1.0)
- Physical Database Design (PDD v1.0)
- Architecture Decision Records (ADR v1.0)
- Master Implementation Backlog (MIB v1.0)
- Technical Coding Standards (TCS v1.0)

---

# Purpose

This document records architectural improvements and design refinements discovered after the initial architecture freeze.

These improvements were identified during the implementation planning phase (Master Implementation Backlog) and have **NOT** yet been merged into the official architecture documents.

This document acts as a temporary review buffer.

No official documentation shall be modified until every revision listed in this document has been reviewed and approved.

After approval, the changes will be incorporated into:

- PRD
- SAD
- DDD
- PDD
- ADR

This document will then become obsolete.

---

# Revision Status

Current Status

Pending Review

Architecture Freeze

Maintained

Implementation

Not Started

Breaking Changes

None

Database Impact

Minor

Module Impact

Medium

---

# Revision 001

## Promote Wedding Event as First-Class Entity

### Background

Originally, Guests were modeled as the primary operational entity.

During implementation planning, it became clear that almost every operational module revolves around individual wedding events rather than the workspace itself.

Examples include:

- Holy Matrimony
- Reception
- Engagement
- Sangjit
- Tea Ceremony
- After Party

### Proposal

Workspace contains one or more Wedding Events.

Wedding Events become the second aggregate root after Workspace.

Every operational module references Wedding Events instead of directly referencing Workspace whenever appropriate.

### Benefits

- Unlimited event support
- Future-proof architecture
- Cleaner dashboard aggregation
- Better reporting
- Better operational separation

### Impact

PRD

SAD

DDD

PDD

---

# Revision 002

## Guest Event Assignment

### Background

Guests should not be limited by hardcoded invitation types.

### Proposal

Guests are assigned to one or more Wedding Events.

Examples

Guest A

✓ Holy Matrimony

✓ Reception

Guest B

✗ Holy Matrimony

✓ Reception

Guest C

✓ Engagement

### Benefits

No hardcoded event logic.

Unlimited event flexibility.

Cleaner database.

### Impact

DDD

PDD

Guest Module

RSVP

Check-in

Communication

Reports

---

# Revision 003

## Dynamic Invitation Rendering

### Background

Invitation pages should not be built around invitation types.

Instead, they should dynamically render invited events.

### Proposal

Invitation Engine renders:

Guest

×

Assigned Wedding Events

The invitation automatically displays all events assigned to the guest.

### Benefits

Single rendering engine.

Unlimited events.

Simpler themes.

Future-proof.

### Impact

PRD

SAD

Invitation Module

Theme Engine

---

# Revision 004

## Unified Guest Experience

### Background

Guests should never experience multiple invitations for one wedding.

### Proposal

Every guest receives

- One Invitation URL
- One Guest Code
- One QR Code
- One Invitation Journey

Invitation content changes dynamically according to assigned events.

### Benefits

Simple user experience.

Less confusion.

Better communication.

### Impact

Invitation

Communication

QR

Guest Journey

---

# Revision 005

## Event-Specific Operational Data

### Background

Although guests experience one invitation, operational data should remain separated.

### Proposal

The following become Event-specific:

- RSVP
- Attendance
- Check-in
- Dashboard
- Statistics
- Reports

### Benefits

Accurate reporting.

Operational clarity.

Real-time monitoring.

### Impact

Dashboard

Reports

Wedding Day

RSVP

---

# Revision 006

## Unified Reminder Communication

### Background

For weddings occurring on the same day, guests should not receive multiple reminder messages.

### Proposal

One guest receives one reminder.

The reminder dynamically summarizes every invited event.

Example

Holy Matrimony

09:00

Reception

18:00

### Benefits

Cleaner communication.

Less spam.

Better guest experience.

### Impact

Communication

Reminder

Invitation

---

# Revision 007

## Event Dashboard Separation

### Background

Couples need statistics for every event independently.

### Proposal

Dashboard provides:

Overall Workspace

↓

Individual Event Cards

Example

Holy Matrimony

Invited

RSVP

Present

Reception

Invited

RSVP

Present

### Benefits

Better operational awareness.

Better reporting.

### Impact

Dashboard

Reports

Analytics

---

# Revision 008

## Event Context for Crew

### Background

Reception crews normally work only for one event.

### Proposal

Crew logs into a specific Wedding Event.

Example

Holy Crew

Reception Crew

Check-in automatically validates guests against the active event.

### Benefits

Faster workflow.

Less operator mistakes.

Cleaner dashboard.

### Impact

Crew

Authentication

Wedding Day

QR

---

# Revision 009

## Vendor Event Assignment (Optional)

### Background

Some vendors serve only one event.

Others serve all events.

### Proposal

Vendor may optionally be assigned to one or more Wedding Events.

Examples

Pastor

Holy Matrimony

Band

Reception

EO

All Events

### Status

Optional

Future Review Required

### Impact

Vendor Module

Timeline

Budget

---

# Summary of Affected Documents

| Document | Revision Required |
|------------|------------------|
| PRD | Yes |
| SAD | Yes |
| DDD | Yes |
| PDD | Yes |
| ADR | Yes (ADR-026) |
| MIB | Minor Review |
| TCS | No |

---

# Approval Workflow

Design Review

↓

Approval

↓

PRD v1.2

↓

SAD v1.2

↓

DDD v1.2

↓

PDD v1.1

↓

ADR-026

↓

Final Architecture Freeze

↓

Sprint 0 Development

---

# Final Statement

This Design Revision Pack documents architectural improvements identified after the initial design freeze.

No revision contained within this document becomes official until formally reviewed and approved.

Once approved, all accepted revisions shall be merged into the official project documentation.

After integration, this document serves as historical reference only and should not be modified further.