From d5c27b4b88abdf668ac2c4975e3731a7556bed80 Mon Sep 17 00:00:00 2001
From: narawat <narawat@gmail.com>
Date: Sun, 22 Mar 2026 22:40:25 +0700
Subject: [PATCH] update

---
 ASG_Framework.md | 55 +++++++++++++++++++++++++++++++-----------------
 1 file changed, 36 insertions(+), 19 deletions(-)

diff --git a/ASG_Framework.md b/ASG_Framework.md
index 1bff084..52c30c8 100644
--- a/ASG_Framework.md
+++ b/ASG_Framework.md
@@ -30,14 +30,16 @@ This document defines the documentation framework for a software project. It est
 - Aligns engineering efforts with business goals
 - Provides a north star for feature development
 - Establishes acceptance criteria before implementation begins
-- Creates a contract between product and engineering
+- Creates a contract between product, engineering, security, and operations.
 
 **Content Guidelines**:
 - User stories with clear acceptance criteria (As a X, I want Y so that Z)
-- Product Requirements Documents (PRDs) with success metrics
-- Non-functional requirements (performance, security, scalability)
-- Boundary definitions (what's in scope vs. out of scope)
-- Do not cite any other documents as requirements.md is the first document to be created in the ASG Framework
+- Product Requirements Documents with clear success metrics and KPIs.
+- Nonfunctional requirements covering performance, scalability, availability, reliability, and privacy.
+- Boundary definitions that state what is in scope and out of scope.
+- Security requirements including threat model outcomes, authentication and authorization expectations, data classification, encryption requirements, and compliance controls.
+- Observability requirements specifying required telemetry, metrics, traces, logs, alerting thresholds, and retention policies.
+- Traceability rule: do not cite other documents as the source of requirements. requirements.md is the canonical first document in the ASG Framework.
 
 **Best Practices**:
 - Link each requirement to a measurable KPI
@@ -401,24 +403,39 @@ Each documentation artifact has associated KPIs. Track these to ensure quality:
 ```markdown
 # PRD: Feature Name
 
-## Business Goal
-[What problem are we solving?]
+## 1. Business Context & Success Metrics
+- Business Goal
+- User Stories (with acceptance criteria)
+- KPIs & Targets (e.g., "99.95% availability", "<200ms p95 latency")
 
-## Success Metrics
-- [Metric 1]: Target [value]
-- [Metric 2]: Target [value]
+## 2. Technical Boundaries
+- In Scope
+- Out of Scope
+- Dependencies (e.g., "Requires Stripe API v2023-08")
 
-## User Stories
-- As a [role], I want [feature] so that [benefit]
-  - Acceptance Criteria: [details]
+## 3. Non-Functional Requirements (NFRs)
+### 3.1 Performance & Scalability
+- [e.g., Support 10K TPS, scale horizontally to 100 nodes]
 
-## Non-Functional Requirements
-- Performance: [details]
-- Security: [details]
-- Scalability: [details]
+### 3.2 Availability & Reliability
+- [e.g., SLO: 99.9% monthly uptime, MTTR < 10min]
 
-## Out of Scope
-- [What's explicitly excluded]
+### 3.3 Privacy & Security
+- Data Classification: [e.g., PII, PHI]
+- Threat Model Outcomes: [e.g., "Mitigates replay attacks via nonce + timestamp"]
+- Auth/Z Expectations: [e.g., RBAC with 3 roles: viewer, editor, admin]
+- Encryption: [e.g., TLS 1.3+, AES-256 at rest]
+- Compliance: [e.g., GDPR Art. 32, SOC2 Type II]
+
+### 3.4 Observability & Telemetry
+- Required Logs: [e.g., `user_id`, `request_id`, `status`, `latency_ms`]
+- Critical Metrics: [e.g., `auth_failures_total`, `api_latency_seconds{quantile=0.99}`]
+- Tracing: [e.g., Zipkin/B3 propagation, 10% sampling]
+- Alerting: [e.g., `auth_failure_rate > 5%/min` triggers PagerDuty]
+- Retention: [e.g., Logs: 30 days, Metrics: 1 year]
+
+## 4. Acceptance Conditions
+- [List verifiable conditions for sign-off, including validation gates]
 ```
 
 ### Specification Template