# ข้อเสนอโครงการ (Proposal)
# PRI Platform — Project Relationship Infrastructure

**Project & Building Lifecycle Platform**  
Pilot: Bangkok Hospital Phuket (Project Delivery) + อาคารภูเก็ต 1 หลัง (Building Inspection)

| รายการ | รายละเอียด |
|---|---|
| เวอร์ชัน | 1.0 |
| วันที่ | 12 สิงหาคม 2569 (2026-08-12) |
| ผู้รับ | ทีมพัฒนา PRI / Sponsor / Owner Pilot |
| ภาษา | ไทยเป็นหลัก · คำศัพท์เทคนิคภาษาอังกฤษตามมาตรฐานอุตสาหกรรม |
| เอกสารอ้างอิง | `meeting_12_สค_2569.txt`, `PRI PLATFORM First Doc.md`, `PRI_Platform_Plan_and_Cost_Estimate.md`, `PRI_Rate_Card_MidMarket.md`, `WebApp_Template/` |

---

## 1. Executive Summary / วิสัยทัศน์

PRI ไม่ใช่แค่ซอฟต์แวร์บริหารงานก่อสร้าง แต่เป็น **โครงสร้างพื้นฐานกลาง (Infrastructure)** ที่เชื่อม

**คน · ข้อมูล · ความรับผิดชอบ · การตัดสินใจ · หลักฐาน · ความเชื่อมั่น**

ตลอดวงจรชีวิต:

> บริหารโครงการ → ก่อสร้าง → ส่งมอบ → ใช้งานอาคาร → ตรวจสอบและดูแลอาคารระยะยาว

### หลักการทำงาน (North Star)

**สร้างของจริง → ใช้กับงานจริง → วัดผลจริง → ปรับปรุง → แล้วค่อย Scale**

หัวใจความแตกต่างไม่ใช่จำนวนเมนู แต่คือ **Data Architecture + Evidence Chain + Decision/Audit Trail** ที่ย้อนกลับได้ถึงต้นเหตุและกฎหมาย

### Tagline

- EN: *Connect People • Integrate Data • Build Trust • Improve Performance*
- TH: *เชื่อมคน เชื่อมข้อมูล สร้างความเชื่อมั่น เพื่อยกระดับประสิทธิภาพของโครงการ*

---

## 2. ขอบเขต Pilot (In Scope)

ช่วงแรกทำ **2 Use Cases จริง** บน Platform เดียวกัน — ไม่รอ Platform สมบูรณ์ก่อนใช้งาน

### Pilot A — Project Delivery (Bangkok Hospital Phuket)

ใช้ปัญหาและเอกสารจริงจากโครงการ BPK เพื่อพัฒนาโมดูล Priority:

| กลุ่ม | โมดูล MVP |
|---|---|
| Command | Executive Dashboard (จาก record จริง) |
| Master | Project Structure & Master Data |
| Operations | Issue / Risk / Action, Meeting → Action/Decision |
| Governance | Document Evidence Hub, Authority & Approval, Decision Center |
| Trust | TII พื้นฐาน (Identity / RBAC / Audit) |
| Lite / ถัดไป | Schedule & Cost (Lite), AI Copilot (หลังมี corpus) |

### Pilot B — Building Inspection (อาคารภูเก็ต 1 อาคาร)

พิสูจน์ว่า PRI ใช้กับ **อาคารที่เปิดใช้งานอยู่แล้ว** ได้จริง ตาม พ.ร.บ.ควบคุมอาคาร พ.ศ. 2522 และกฎกระทรวงที่เกี่ยวข้อง:

`ข้อมูลอาคาร → Checklist → แผนตรวจ → ตรวจหน้างาน → รูปหลักฐาน → Finding → CAPA → รายงาน → ติดตามปิดประเด็น / Submission`

### นอกขอบเขต MVP (สรุป)

- ครบ 11 Modules ระดับ Production ทันที
- Multi-tenant SaaS / Billing / Marketplace
- ครอบคลุมกฎหมายทุกจังหวัด / อาคาร 9 ประเภทพร้อมกัน
- Native App Store (ใช้ PWA/Tablet ก่อน)
- เชื่อมเจ้าพนักงานท้องถิ่นอัตโนมัติ / e-Signature เต็มรูป
- AI รับรองความปลอดภัยหรือกฎหมายแทนผู้มีอำนาจ

---

## 3. บทบาททีม

| คน | มุม | ส่งมอบหลัก |
|---|---|---|
| พี่ชวกร | Owner / PM / การใช้งานจริง | Workflow จริง, เอกสาร BPK, อาคาร pilot, Feedback |
| พี่ป๋อง | Technology / Architecture / Dev | Schema, API, Workflow, RBAC, Prototype, Delivery |
| Process Lead | PRI Standard / Decision Support / TII / Business Model | PRI Standard, Decision Matrix, User Story, AC, Trust |

---

## 4. WebApp_Template ส่งผลต่อแนวทาง Implement อย่างไร

โฟลเดอร์ `C:\Projects\PRI\WebApp_Template` คือ **ชุด UI Concept / Journey** (Public → Sign In → Request Access → Onboarding → Platform) ที่จัดแนวทาง Product และ Architecture ดังนี้:

| จาก Template | นำไปใช้ใน Proposal / MVP |
|---|---|
| Sign-in + Org SSO (Microsoft / Google / Enterprise SSO) | Auth ผ่าน OIDC; รองรับองค์กรโรงพยาบาล/ที่ปรึกษา |
| “Protected by TII Trust Layer” บนหน้า Login | Trust ไม่ใช่เมนูแยก — เป็นชั้นกลางของทุก Action |
| Request Access: User → Organization → Portfolio → Project → Role → Authority | ลำดับ Entity หลักใน Database และ Onboarding API |
| Onboarding 7 ขั้น (Org → Portfolio → Project → People → Data → Governance → Ready) | Workflow เริ่มต้นก่อนเข้า Executive Command Center |
| Sidebar โมดูล (Projects, Issues & Risks, Meetings, Documents, Cost, AI, Governance) | จัดกลุ่ม API / Navigation ให้สอดคล้อง Part A |
| AI Intelligence Layer (Ask → Retrieve → Verify → Reason → Cite → Recommend → Human Decision) | AI Copilot แบบ grounded + citation; Human-in-the-loop |
| Trust Chain (Identity → Authority → Purpose → Policy → Permit/Block → Evidence → Monitor) | ออกแบบ TII intercept ทุก critical action |
| ค่าหลัก: One Source of Truth / Evidence-Based / Trust & Governance | Acceptance Criteria และ KPI ของ Pilot |

**ข้อสรุปด้านเทคนิคจาก Template + แผนงาน:**  
Web App แบบ Responsive (Desktop + Tablet Field) · HTTPS เป็นค่าเริ่มต้น Production · API กลาง · PostgreSQL · Object Storage สำหรับ Evidence · PWA สำหรับ Field Inspection · ไม่แตก Microservices เกินจำเป็นใน MVP

> รายละเอียด Deploy: Production ต้องใช้ **HTTPS/TLS**, redirect HTTP→HTTPS, และ cookie `Secure; HttpOnly; SameSite` เมื่อมี Auth — UI ต้องใช้งานได้บนมือถือ/แท็บเล็ตโดยไม่มี horizontal scroll

---

## 5. System Architecture

![System Architecture](images/System_Architecture.png)

### ภาพรวมสถาปัตยกรรม (Monolith Modular — ไม่ใช่ microservice กระจาย)

```
┌─────────────────────────────────────────────────────────────┐
│  Clients: Web App (Responsive) · Field PWA/Tablet · Admin   │
└───────────────────────────┬─────────────────────────────────┘
                            │ HTTPS / OIDC
┌───────────────────────────▼─────────────────────────────────┐
│                 TII Trust Layer (Common)                      │
│  Identity · Authority/RBAC · Audit · Lineage · AI Guardrails │
└───────────────────────────┬─────────────────────────────────┘
                            │
        ┌───────────────────┼───────────────────┐
        ▼                   ▼                   ▼
┌───────────────┐   ┌───────────────┐   ┌──────────────────┐
│ Part A        │   │ Part B        │   │ Shared Services  │
│ Project       │   │ Building      │   │ Evidence Store   │
│ Delivery      │   │ Inspection &  │   │ Workflow (light) │
│ (BPK Pilot)   │   │ Compliance    │   │ Notify · Files   │
└───────┬───────┘   └───────┬───────┘   └────────┬─────────┘
        │                   │                    │
        └───────────────────┼────────────────────┘
                            ▼
              PostgreSQL · Object Storage · Rules Config
```

### ส่วนประกอบหลัก

| ชั้น | หน้าที่ |
|---|---|
| **Presentation** | Dashboard, Forms, Field Checklist, AI Copilot UI (ตาม WebApp_Template) |
| **API Gateway / App API** | REST/JSON ทรัพยากรตามโดเมน; บังคับ AuthZ ผ่าน TII |
| **Part A — Project Delivery** | Issue/Risk, Meeting, Docs, Approval, Decision, Dashboard |
| **Part B — Building Inspection** | Building Profile, Legal Rules (config), Plan, Field, Finding/CAPA, Report |
| **TII Trust Layer** | Identity, Authority, Purpose, Policy, Permit/Block, Evidence Log, Monitoring |
| **Data** | PostgreSQL (records) + Object Storage (ไฟล์/รูป + hash) + Rules Repository |
| **AI (ภายหลังข้อมูลพอ)** | Grounded retrieval + citation; ห้ามลงนาม/ปิด Finding Critical |

### Lifecycle Evidence Chain (เชื่อม Part A ↔ Part B)

`Design → Construction → Inspect/Test → Handover → Operation → Statutory Inspection → Maintain/Renovate`

---

## 6. Database (Entities / ER Overview)

![Database ER Overview](images/Database.png)

### 6.1 โครงสร้างองค์กร (จาก Template)

`User` → `Organization` → `Portfolio` → `Project` / `Building`  
พร้อม `Membership`, `Role`, `Authority` (ขอบเขต Project หรือ Building)

### 6.2 Entity หลัก — Part A (Project Delivery)

| Entity | ความสัมพันธ์สำคัญ |
|---|---|
| Project, WBS/Package, Vendor, Zone/Room | Master data |
| Issue, Risk, Action | Owner, Severity, Due, Status, Evidence links |
| Meeting, AgendaItem, Minute, Decision | Meeting → Action/Decision |
| Document, DocumentVersion | Metadata + link ไป Issue/Approval/Decision |
| ApprovalRequest (RFA/RFI/Submittal) | Authority Matrix + SLA |
| DecisionRecord | Options, Impact, Rationale, Approver |

### 6.3 Entity หลัก — Part B (Inspection) — Evidence Chain

`Law → Requirement → Building → InspectionItem → Evidence → Finding → Risk → CorrectiveAction → Verification → Certificate/Submission → AuditTrail`

| Entity | ฟิลด์สำคัญ (ย่อ) |
|---|---|
| Law | Version, Effective Date, Jurisdiction, Source |
| Requirement | Clause, Applicability, Frequency, Evidence Type |
| Building | Use type, Area, Height, Floors, Local Authority |
| InspectionPlan / Item | Method, Acceptance Criteria, Due, Owner |
| Evidence | File/Photo/Test, Timestamp, Creator, Hash |
| Finding | Severity, Status, Party |
| CorrectiveAction (CAPA) | Owner, Due, Evidence Required |
| Verification | Verifier ≠ Fixer (SoD), Re-test |
| Submission | Signer, Submitted Date, Authority, Status |

### 6.4 Trust / Cross-cutting

`Identity`, `RoleAssignment`, `PolicyVersion`, `AuditEvent` (Actor, Action, Object, Before/After, Timestamp, Policy Version)

**หลักการข้อมูล:** ทุก record สำคัญมี Unique ID, Owner, Status, Created/Updated By/At, History — KPI ต้องมาจาก record ที่ traceable ไม่ใช่ตัวเลขพิมพ์มือ

---

## 7. API (High-level Map)

![API Map](images/API.png)

รูปแบบ: **HTTPS + REST/JSON** · Versioned (`/api/v1`) · ทุกคำขอผ่าน TII (AuthN → AuthZ → Audit)

### 7.1 Identity & Trust

| Resource | ตัวอย่าง |
|---|---|
| Auth / Session | `POST /auth/login`, OIDC callback, `POST /auth/logout` |
| Access Request | `POST /access-requests`, `PATCH /access-requests/{id}` |
| Users / Memberships | `GET/POST /orgs/{orgId}/members` |
| Roles / Authority | `GET/PUT /projects/{id}/roles`, authority matrix |
| Audit | `GET /audit-events?entity=&from=` |

### 7.2 Onboarding & Master

| Resource | ตัวอย่าง |
|---|---|
| Organizations / Portfolios | `POST /orgs`, `POST /orgs/{id}/portfolios` |
| Projects | `POST /projects`, `GET /projects/{id}` |
| Buildings | `POST /buildings`, `GET /buildings/{id}/profile` |
| Import | `POST /imports` (CSV/XLSX metadata bind) |

### 7.3 Part A — Project Delivery

| Domain | Resources (ย่อ) |
|---|---|
| Issues & Risks | `/projects/{id}/issues`, `/risks`, `/actions` |
| Meetings | `/meetings`, `/meetings/{id}/decisions` |
| Documents | `/documents`, `/documents/{id}/versions` |
| Approvals | `/approvals`, `/approvals/{id}/decide` |
| Decisions | `/decisions` |
| Dashboard | `/projects/{id}/kpis` (คำนวณจาก records) |

### 7.4 Part B — Inspection & Compliance

| Domain | Resources (ย่อ) |
|---|---|
| Legal | `/laws`, `/requirements` (versioned config) |
| Applicability | `POST /buildings/{id}/applicability/confirm` |
| Plans | `/buildings/{id}/inspection-plans` |
| Field | `POST /inspection-items/{id}/results` (+ evidence upload) |
| Findings / CAPA | `/findings`, `/corrective-actions`, `/verifications` |
| Reports / Submission | `/reports`, `/submissions` |
| Calendar | `/buildings/{id}/compliance-calendar` |

### 7.5 Evidence & AI

| Domain | Resources (ย่อ) |
|---|---|
| Evidence | `POST /evidence` (multipart → object storage + hash) |
| AI Copilot | `POST /ai/query` → answer + citations + “recommendation only” flag |

**หมายเหตุ:** ไม่ออกแบบเป็นชุด microservice แยกต่อโมดูลใน MVP — เป็น **modular monolith API** ที่ขยายโดเมนตาม Pilot

---

## 8. Workflow

![Key Workflows](images/Workflow.png)

### 8.1 Access & Onboarding (จาก Template)

1. Verify Identity  
2. Verify Organization  
3. Assign Role & Authority  
4. Create Workspace  
5. Onboarding: Org → Portfolio → Project → People → Data → Governance → **PRI Ready**

### 8.2 Project Delivery — Decision Loop (BPK)

`Issue/Risk เกิด → ผูก Evidence → Meeting/Action → Approval (ถ้าต้อง) → Decision Record → Dashboard / Overdue`

### 8.3 Building Inspection & CAPA (Pilot B)

1. Register Building  
2. Determine Applicability (Rules เสนอ → คนมีอำนาจยืนยัน)  
3. Generate Inspection Plan  
4. Field Inspection (Checklist + Photo + Note)  
5. Finding & Risk  
6. Corrective Action (CAPA)  
7. Verification / Re-test (**ห้ามคนแก้ปิดเอง** เมื่อ SoD บังคับ)  
8. Report & Sign status  
9. Submission Tracking  
10. Renewal Calendar  

### 8.4 AI Assist (ไม่แทนผู้มีอำนาจ)

`Ask → Retrieve → Verify → Reason → Cite Evidence → Recommend → **Human Decision**`

---

## 9. TII Trust Layer

TII เป็น **ชั้นร่วมของทั้งสอง Pilot** — ไม่ใช่ฟีเจอร์ปลายทาง

| หลักการ | ความหมายในการออกแบบ |
|---|---|
| Verify Before Access | ยืนยันตัวตนและสิทธิ์ก่อนเข้าข้อมูล/Action |
| Continuous Trust | ตรวจซ้ำตาม Policy / Session / Scope |
| Privacy by Design | PDPA-aware: Purpose, least privilege, audit |

### Trust Chain (ทุก Critical Action)

`IDENTITY → AUTHORITY → PURPOSE → POLICY → PERMIT/BLOCK → EVIDENCE LOG → CONTINUOUS MONITORING`

### ครอบคลุม

- Human Access (RBAC / SoD)  
- AI Access & AI Action Control (ห้าม sign / ปิด Critical Finding)  
- Data Access ตามความอ่อนไหว  
- Decision Authority  
- Auditability + Data Lineage  

เป้าหมายมาตรฐานระยะยาว (ไม่บังคับครบใน MVP): PDPA · ISO 27001-aligned controls · SOC 2 readiness · GDPR-ready patterns · NIST-aligned practices

---

## 10. กฎหมายและมาตรฐานที่เกี่ยวข้อง (Pilot B + Hospital Context)

> เอกสารนี้เป็น System/Product Design **ไม่ใช่** คำวินิจฉัยทางกฎหมาย — Rule ที่ใช้จริงต้องให้ผู้ตรวจสอบอาคาร/ผู้เชี่ยวชาญยืนยันฉบับและ Applicability

| กลุ่ม | เอกสารหลัก |
|---|---|
| กฎหมายแม่บท | พ.ร.บ.ควบคุมอาคาร พ.ศ. 2522 และที่แก้ไข |
| ประเภทอาคารที่ต้องมีผู้ตรวจ | กฎกระทรวง พ.ศ. 2548 (อาคาร 9 ประเภท) |
| คุณสมบัติผู้ตรวจ / หลักเกณฑ์ตรวจ | กฎกระทรวง พ.ศ. 2548 (ตรวจประจำปี / ตรวจใหญ่ทุก 5 ปี) |
| อาคารสูง / ขนาดใหญ่พิเศษ | กฎกระทรวง ฉบับที่ 33 (2535), 55 (2543) |
| สถานพยาบาล | พ.ร.บ.สถานพยาบาล พ.ศ. 2541 |
| Universal Design | กฎกระทรวงสิ่งอำนวยความสะดวก พ.ศ. 2548 |
| มาตรฐานวิชาชีพ | EIT, สภาวิศวกร / สภาสถาปนิก |

แหล่งอ้างอิง: [DPT](https://www.dpt.go.th) · [BSA](https://www.bsa.or.th) · [EIT](https://eit.or.th) · [COE](https://www.coe.or.th)

**Rules Engine:** เก็บเป็น Configuration (Version + Effective Date) แยกจาก Source Code — เมื่อกฎหมายเปลี่ยน ระบบ flag อาคาร/Checklist ที่กระทบ โดยไม่เขียนทับประวัติผลตรวจเก่า

---

## 11. แผนงาน Implement และต้นทุน (อ้างอิง)

รายละเอียดเต็ม: `../PRI_Platform_Plan_and_Cost_Estimate.md` และ `../PRI_Rate_Card_MidMarket.md`

### เฟส

| Phase | ขอบเขต | ระยะเวลา (Likely) |
|---|---|---|
| 0 Discovery / Foundation | เอกสารจริง, Scope Freeze, Entity/Arch v0.1, CI/Env | ~3 สัปดาห์ |
| 1 Pilot A BPK | โมดูล Priority + TII พื้นฐาน | ~14 สัปดาห์ |
| 2 Pilot B Inspection | Workflow ตรวจอาคาร 1 หลังครบ Evidence Chain | ~12 สัปดาห์ (ทับซ้อนท้าย Phase 1 ได้) |
| 3 Hardening | AI v0.1, Offline ดีขึ้น, Security/Ops, Scale prep | ~10 สัปดาห์ |

### ต้นทุนโดยประมาณ (THB, ไม่รวม VAT 7%)

| แพ็กเกจ | Low | **Likely** | High |
|---|---:|---:|---:|
| **A. MVP Pilots** (Phase 0+1+2) | ~3.8M | **~5.7M** | ~8.5M |
| **B. + Hardening** (0+1+2+3) | ~5.1M | **~7.7M** | ~11.5M |

- Effort MVP ≈ **583 man-days** · Blended Likely ≈ **9,500 THB/MD** (Boutique / Mid-market)  
- Hybrid core team ลงแรงเอง: cash outlay อาจลดประมาณ 25–40% แต่ต้องนับ opportunity cost  
- Year-1 OpEx (hosting + LLM + monitor) Likely ประมาณ **0.6–0.9M THB/ปี** (ไม่รวม major CR)

**คำแนะนำ:** อย่าตัด TII / Evidence / Rules Versioning ออกจากงบ Pilot — นั่นคือ moat ของ PRI

---

## 12. KPI และเกณฑ์ความสำเร็จ Pilot

| KPI | เป้า |
|---|---|
| Traceability (Finding → Requirement + Evidence) | ≥ 95% |
| Evidence completeness ตาม Rule | ≥ 90% |
| CAPA มี Owner / Due / Status | 100% |
| Critical actions มี Actor / Authority / Timestamp | 100% |
| UAT ผู้ใช้จริง (workflow หลัก) | ≥ 80% scenario |
| Report efficiency | ลดเวลาสร้างรายงานจาก baseline อย่างมีนัย |

---

## 13. ความเสี่ยงหลักและการควบคุม

| ความเสี่ยง | Control |
|---|---|
| Scope ใหญ่เกิน | Vertical Slice + Scope Freeze ที่ Milestone M0 |
| แปลกฎหมายผิด | Inspector/Legal Reviewer อนุมัติ Rule |
| Hard-code rules | Rules Repository + versioning |
| AI hallucination | Grounded only + citation + ห้ามรับรองแทนคน |
| SoD หลวม | คนแก้ ≠ คน Verify; immutable audit |
| ไม่มีข้อมูล/Finding จริง | เกณฑ์เลือกอาคารบังคับมีเคสจริง |

---

## 14. Next Steps ที่เสนอ (14 วันแรก)

1. Shared Data Room ตามโครงสร้าง First Doc §20  
2. BPK ส่งตัวอย่างเอกสารโมดูล Priority  
3. Legal Pack + Checklist + รายงานตัวอย่าง + เลือกอาคาร pilot  
4. ร่าง Entity Model + API Contract จากเอกสารนี้  
5. Workshop 90 นาที: walkthrough 2 end-to-end use cases  
6. Freeze MVP Backlog + Acceptance Criteria  
7. ยืนยัน stack สุดท้าย (React/Next หรือเทียบ + API Node/Nest หรือ .NET + PostgreSQL) และขึ้น staging แบบ HTTPS  

---

## 15. ภาคผนวก — ภาพประกอบ

| ไฟล์ | คำอธิบาย |
|---|---|
| [images/System_Architecture.png](images/System_Architecture.png) | สถาปัตยกรรม Platform · Part A/B · TII |
| [images/Database.png](images/Database.png) | ER / Data Model Overview |
| [images/API.png](images/API.png) | API layers และ resource map |
| [images/Workflow.png](images/Workflow.png) | Onboarding · Delivery · Inspection/CAPA |

เอกสารพิมพ์อ่านง่าย: [PRI_Platform_Proposal.html](PRI_Platform_Proposal.html)

---

*เอกสารนี้ใช้ประกอบการเสนอแนวทางและตัดสินใจร่วม ไม่ใช่ใบเสนอราคาผูกมัด และไม่ใช่คำปรึกษาทางกฎหมาย*
