Standards

Standards are the expectations every team builds within: SLO tiers, data residency, logging formats, API conventions. In ArchForge a standard has a clear scope and concrete requirements, and it only becomes binding once a reviewer publishes it.

Standards are available on the Pro and Enterprise plans. You need the Member role or higher to create one.

1. Create a standard

1. Open Standards in the sidebar and choose + New Standard.
2. Enter a Title, for example Service tiering & SLO policy.
3. Add any co-authors under Authors.
4. Fill in Body (Markdown). It starts from your workspace's standard template, which by default has these sections:
   • Purpose: why the standard exists and the outcome it drives.
   • Scope: what it applies to, and any explicit exclusions.
   • Requirements: the rules themselves, written as MUST, SHOULD, and MAY statements.
   • Rationale: why these requirements were chosen.
   • Compliance: how conformance is measured and reported.
   • Exceptions: how to request an exception, and who approves it.
5. Choose Create draft.

Your standard starts in Draft. Choose Edit, then Save draft, to keep refining it. Admins can tailor the template to your governance model in Artifact types and templates.

2. Make it binding

Standards use the shared review flow:

1. Choose Propose for review and pick a reviewer.
2. The reviewer chooses Publish, Reject, or Request changes.
3. If changes are requested, tick off each checklist item as you address it, then choose Resubmit for review. It returns to the same reviewer.

Only a Published standard is authoritative. See Reviewing and approving for the full flow.

3. Change a standard without confusion

The body of a standard can only be edited while it is a draft or has changes requested. Once published, it stays exactly as approved. When the rules need to change:

1. Write the new version as a new standard and take it through review.
2. Open the old standard and choose Supersede, or choose Deprecate if it is simply no longer needed.

The old standard is never silently edited away, so teams can always see what applied and when.

Writing good requirements

• Use MUST for rules that block a release, SHOULD for strong expectations, and MAY for options.
• Make each requirement checkable. "Tier 1 services page on-call within 5 minutes" can be verified; "services should be reliable" cannot.
• Say in Compliance who checks conformance and when, for example at solution design review.