Engineering Standards – Overview¶

Purpose: Define the scope, intent, and governance of engineering standards at Tinggit
Audience: Engineering, Architecture, Security, QA, Product Leadership

• Table of contents
• Engineering Standards – Overview
  • 1. Purpose of Engineering Standards
  • 2. Scope of This Section
  • 3. What Belongs in Engineering Standards
  • 4. What Does NOT Belong Here (Very Important)
  • 5. Relationship to Other Wiki Sections
  • 6. Current and Planned Standard Areas
  • 7. Governance & Change Rules
  • 8. Enforcement Expectations
  • 9. Final Statement

---

1. Purpose of Engineering Standards¶

Engineering Standards exist to ensure that Tinggit builds software that is:

• Reliable
• Secure
• Maintainable
• Scalable
• Audit-ready

These standards define how we build, not what we build.

bq. Standards protect long-term quality, even when delivery pressure is high.

---

2. Scope of This Section¶

The Engineering Standards section governs:

• Coding practices
• Architecture principles
• API and integration guidelines
• Security and compliance expectations
• Branching, PR, and review discipline

These standards apply to:

• All services
• All UIs
• All repositories
• All contributors

---

3. What Belongs in Engineering Standards¶

Engineering Standards pages must contain:

• Long-lived rules
• “Must / Must Not” expectations
• Principles that survive multiple sprints
• Cross-team consistency requirements

Examples:

• Naming conventions
• Error-handling expectations
• Security baselines
• Architectural constraints

---

4. What Does NOT Belong Here (Very Important)¶

The following must never be stored in Engineering Standards:

• Step-by-step tutorials
• Framework-specific how-to guides
• Temporary implementation decisions
• Sprint-specific design notes
• Experimental spike outcomes

Rules:

• If it changes sprint-to-sprint → it does not belong here
• If it is specific to one issue → it belongs in the issue

---

5. Relationship to Other Wiki Sections¶

Engineering Standards are orthogonal to delivery processes.

Area	Responsibility
Product Process	How work is planned and delivered
Sprint Rules	How execution is governed
Engineering Standards	How code is written and structured
Role Guides	How people apply standards and process

Engineering Standards do NOT override:

• Product priorities
• Sprint commitments
• Release governance

---

6. Current and Planned Standard Areas¶

The following standard areas may be added under this section:

• Coding Standards
• Architecture Principles
• API & Integration Guidelines
• Security & Compliance Practices
• Branching & PR Guidelines

Each area must:

• Have a clear owner
• Be reviewed periodically
• Avoid duplication with other sections

---

7. Governance & Change Rules¶

To keep standards effective:

• Standards must be reviewed before addition
• Changes must be intentional and documented
• Breaking changes must be communicated
• Old standards must be deprecated, not deleted

If a standard changes:

• Create a new version or page
• Reference the old one
• Preserve history

---

8. Enforcement Expectations¶

Engineering Standards are enforced through:

• Code reviews
• Automated checks (where applicable)
• QA validation
• Architecture review (when required)

Standards are not optional.

Exceptions must be:

• Explicit
• Documented
• Approved

---

9. Final Statement¶

bq. Engineering Standards are not about control.

They are about enabling teams to move fast
without breaking what they have already built.

This page defines the boundaries.
Future standards must respect them.