Project

General

Profile

Wiki » History » Revision 3

Revision 2 (Redmine Admin, 12/26/2025 03:27 PM) → Revision 3/4 (Redmine Admin, 12/26/2025 03:38 PM)

h1. Tinggit Platform Wiki – Operating Model & Knowledge Architecture Hub 

 *This page is the authoritative root of the entry point for how Tinggit Platform Wiki.* 
 *It defines where every type of information must live — now plans, builds, ships, governs, and in the future.* evolves its products.* 

 {{toc}} 

 --- 

 h2. 1. Purpose of This Wiki 

 The Tinggit Platform Wiki is serves as the **long-term memory and operating system** for how Tinggit works. **single source of truth** for: 

 It exists to: 

 * Standardize how How work is delivered executed (process & delivery) 
 * Preserve sprint How decisions are made and release history remembered 
 * Capture How quality, compliance, and risk are managed 
 * How engineering standards are applied 
 * Record decisions, risks, Why product and opportunities business choices exist 

 This wiki exists to: 
 * Enable consistent execution 
 * Preserve organizational memory 
 * Support audits, compliance, audits and scale compliance 
 * Scale teams without losing clarity 

 *bq.* If information something is not placed in the correct section of this wiki, documented here, it is considered unofficial. not part of the official operating model. 

 --- 

 h2. 2. How to Use This Wiki (Very Important) 

 This Different audiences should use this wiki is **not a single document**. 
 It is a *structured system*. differently: 

 Before creating or updating any page, ask: 

 * What type of information is this? |_. Role |_. Start Here | 
 * Is it stable or sprint-specific? | Product Owners | Role-Based Guides → Product Owner Training Guide | 
 * Does it define rules or describe usage? | Engineers | Role-Based Guides → Sprint Team Training Guide | 
 * Will we need this information next year? | QA / Compliance | Role-Based Guides → QA & Compliance Training Guide | 
 | Leadership | Product & Business + Metrics & Audit | 
 | New Joiners | How We Work at Tinggit | 

 The answers determine *where it belongs*. If multiple pages appear related, always follow the **hierarchy defined below**. 

 --- 

 h2. 3. Wiki Architecture Overview (Single Source of Truth) Structure & Governance Model 

 All This wiki content must live under **one of the sections below**. 
 No exceptions. is organized into **six controlled sections**. 

 Each section has a clear purpose and strict boundaries. 

 --- 

 h2. 4. 1️⃣ Operating Model (HOW We Work – Authoritative Rules) Delivery & Process (Authoritative) 

 This section defines **mandatory rules** for how Tinggit delivers software. 

 *how work must be done*.   
 These pages: 
 * Are authoritative 
 * Override all other pages 
 * Must are **rules**, not be duplicated 
 * Must not be reinterpreted suggestions. 

 Pages in this section: 

 * [[Product Process Guidelines]] 
 * [[Sprint Open Process]] 
 * [[Sprint Execution Rules]] 
 * [[Sprint Close Process]] 
 * [[Sprint History, Metrics & Audit]] 
 * [[Release Management Process]] 
 * [[Edge Case & Exception Handling]] 

 *bq.* If there is a conflict, Rules: 
 * These pages in this section always win. override all others 
 * They must not be duplicated 
 * Changes require review 

 --- 

 h2. 5. 2️⃣ Role-Based Guides (HOW to Follow the Rules) (Usage & Training) 

 This section explains **day-to-day usage** of *how to apply the operating model. process* in day-to-day work. 

 These pages: 
 * Explain actions, actions 
 * Do not define rules 
 * Never redefine process 
 * Always link back to Operating Model authoritative process pages 

 Pages in this section: 

 * [[Product Owner Training Guide]] 
 * [[Sprint Team Training Guide]] 
 * [[QA & Compliance Training Guide]] 

 --- 

 h2. 6. 3️⃣ Product & Business Context 

 This section captures *what* we are building and *why*. 

 It provides long-term context and decision alignment. 

 * [[Tingg Insight Business Requirements Document]] 
 * [[Tingg Insight HIPAA Compliance Scope & Applicability]] 
 * Product Vision & Goals *(to be added)* 
 * Product Roadmap (High-Level) *(to be added)* 

 Rules: 
 * These pages do not track execution 
 * They do not replace backlog items 
 * They provide intent, not commitments 

 --- 

 h2. 7. Engineering Standards (HOW We Build) 

 This section defines **technical and engineering standards** that apply across all products. architectural expectations**. 

 This section is for: These pages describe: 
 * Stable, long-lived standards Standards 
 * “Must / Must not” technical rules Principles 
 * Architecture and security principles Non-negotiable practices 

 This section is They do NOT for: contain: 
 * Tutorials 
 * Setup guides 
 * Sprint-specific Temporary implementation notes 
 * Temporary experiments Sprint-specific instructions 

 Pages in this section include: 

 Recommended pages: 
 * Coding Standards 
 * Architecture Principles 
 * API & Integration Guidelines 
 * Security & Compliance Practices 
 * Branching & PR Guidelines 

 --- 

 h2. 7. 4️⃣ Product & Business Context (WHY We Build) 

 This section captures **product intent and business boundaries**. 

 These pages: 
 * Explain *why* work exists 
 * Do NOT track execution 
 * Do NOT replace backlog items 

 Pages in this section: 

 * [[Tingg Insight Business Requirements Document]] 
 * [[Tingg Insight HIPAA Compliance Scope & Applicability]] 
 * Product Vision & Goals 
 * Product Roadmap (High-Level) 

 --- 

 h2. 8. 5️⃣ Decision, Risk & Opportunity Register (WHY Choices Were Made) 

 This section preserves **strategic memory**. 

 It answers: 
 * Why a decision was taken made 
 * What risks were accepted 
 * What opportunities were identified 

 Pages in this section: 

 Recommended pages: 
 * Key Decisions (ADR-lite) (ADR-style, lightweight) 
 * Risk Register 
 * Opportunity Register 

 These pages prevent: 
 * Loss of context 
 * Repeated Repeating past mistakes 
 * Hindsight bias 
 * Loss of context during growth 

 --- 

 h2. 9. 6️⃣ Sprint Records (HISTORICAL – Read Only) Reference & Supporting Material 

 This section stores **sprint-level historical summaries**. contains stable reference information. 

 Each sprint may have ONE wiki page. 

 Structure: 

 <pre> Examples: 
 Sprint Records 
 ├── Sprint YYYY-NN 
 </pre> 

 Sprint wiki pages may contain: 
 * Sprint Goal Glossary 
 * Outcome summary External documentation links 
 * Final velocity 
 * Spillover summary 
 * Retrospective action items (linked issues) Tooling references 

 Sprint wiki pages must NOT contain: Rules: 
 * Task tracking No process definitions 
 * Daily updates 
 * Status changes 
 * Rewritten metrics No operational rules 

 *bq.* Sprint execution lives in issues, not in wiki. 

 --- 

 h2. 10. 7️⃣ Reference & Templates (Reusable Assets) 

 This section contains **reusable templates and stable references**. 

 Structure: 

 <pre> 
 Reference & Templates 
 ├── Templates 
 │     ├── Sprint Wiki Template 
 │     ├── Risk Entry Template 
 │     ├── Decision Record Template 
 │     └── Release Notes Template 
 └── Glossary & External Links 
 </pre> 

 Templates are tools — not content. 

 --- 

 h2. 11. Governance Rules (Mandatory) 

 To keep this wiki reliable and scalable: effective: 

 * Every page must belong to exactly one section 
 * No sprint-specific tracking outside Sprint Records new process pages without review 
 * No process duplication of authoritative content 
 * No temporary content Sprint- or release-specific notes must not live here 
 * Temporary information belongs in issues, not wiki 
 * No rewriting of sprint or release history 

 Violations create lead to confusion and destroy loss of trust. 

 --- 

 h2. 12. Golden Placement Rule (Memorize This) 11. Change Management 

 *bq.* If information changes sprint-to-sprint → it belongs in issues.   
 *bq.* If information must be remembered next year → it belongs in wiki. Changes to this wiki must: 

 * Be intentional 
 * Be reviewed 
 * Preserve history 
 * Avoid rewriting the past 

 This ensures: 
 * Auditability 
 * Stability 
 * Long-term usefulness 

 --- 

 h2. 13. 12. Final Statement 

 *bq.* This wiki is not documentation for documentation’s sake. 

 It is the **operating backbone system of the Tinggit Platform** — 
   
 designed to scale people, products, decisions, and compliance 
 decisions without chaos. 

 Start here. 
 Place information correctly. 
 Follow the structure. Do not improvise.