diff --git a/.github/ISSUE_TEMPLATE/architecture-question.md b/.github/ISSUE_TEMPLATE/architecture-question.md
new file mode 100644
index 0000000..dac83ac
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/architecture-question.md
@@ -0,0 +1,48 @@
+---
+name: Architecture Question
+about: Ask the architecture board for guidance or consultation
+title: ""
+labels: architecture-question
+assignees: ""
+---
+
+## What do you need help with?
+
+<!--
+No question is too small! We'd rather you ask early than fix expensive mistakes later.
+
+Examples:
+- "Should I use REST or GraphQL for this API?"
+- "How do I integrate with the user portal?"
+- "Is there a standard for sample metadata?"
+- "Can you review my design?"
+- "Is there an existing solution for X that I should build upon"
+- "Has another team already solved this problem?"
+- "What are other groups doing for authentication that I could align with?"
+- "Are there existing patterns or libraries I should reuse for this?"
+-->
+
+## Context
+
+<!-- What are you building or planning? Any background that helps us understand? -->
+
+## What you've considered (optional)
+
+<!--
+If you've thought about options, share them. If not, that's totally fine!
+We're here to help you think through it.
+-->
+
+## Timeline
+
+<!-- When do you need guidance? No pressure, just helps us prioritize. -->
+
+## Additional Information
+
+<!-- Anything else that might be helpful? Diagrams, links, examples? -->
+
+---
+
+💡 **Tip:** For urgent requests, add the `urgent` label. For decisions affecting all platforms, consider adding `high-impact`.
+
+🤝 **We're here to help!** Response time target: 2 weeks for initial feedback.
diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml
new file mode 100644
index 0000000..9afb0de
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/config.yml
@@ -0,0 +1,8 @@
+blank_issues_enabled: true
+contact_links:
+  - name: 📚 Documentation
+    url: https://scilifelab.github.io/architecture/
+    about: Read our process documentation and existing decisions
+  - name: 💬 Direct Contact
+    url: mailto:architecture@scilifelab.se
+    about: Email the architecture board directly
diff --git a/docs/decisions/0003-use-single-process-approach-for-architecture-requests.md b/docs/decisions/0003-use-single-process-approach-for-architecture-requests.md
new file mode 100644
index 0000000..43304cf
--- /dev/null
+++ b/docs/decisions/0003-use-single-process-approach-for-architecture-requests.md
@@ -0,0 +1,98 @@
+# ADR-0003. Use Single-Process Approach for Architecture Requests
+
+Date: 2025-11-26
+
+## Status
+
+Accepted
+
+## Context
+
+Architecture governance can use tiered processes (Quick Reviews → ADRs → RFCs) where requesters must choose the appropriate tier. However, this creates:
+
+- Cognitive overhead: "Which tier is this?"
+- Procedural confusion about process selection
+- Need to migrate requests between tiers
+- Higher barrier to asking questions
+
+We want to encourage early engagement before problems become expensive.
+
+## Decision
+
+Use a **single unified process** where formality emerges naturally from impact.
+
+**Process:**
+
+```mermaid
+flowchart LR
+    A[Open Issue] --> B{Discussion<br/>Time varies}
+    B -->|Simple| C[Close with<br/>Answer]
+    B -->|Complex| D[Create ADR PR]
+    D --> E[Publish]
+
+    style A fill:#e1f5ff
+    style D fill:#fff4e1
+    style E fill:#e8f5e9
+```
+
+**Key insight:** Same process, different discussion length based on natural impact.
+
+**Label:** `architecture-question`
+
+**Optional:** `high-impact`, `urgent`
+
+## Rationale
+
+**Single process eliminates confusion:**
+
+- No tier selection needed
+- No migrations between systems
+- Natural scaling based on impact
+
+**Formality emerges from context:**
+
+| Impact | Discussion | Outcome         |
+| ------ | ---------- | --------------- |
+| Low    | 3-5 days   | Answer in issue |
+| Medium | 1-2 weeks  | Likely ADR      |
+| High   | 2-4 weeks  | Definitely ADR  |
+
+**"Question" lowers barrier:**
+
+- Less intimidating than "decision"
+- Encourages early consultation
+- Welcomes exploratory discussion
+
+## Consequences
+
+**Positive:**
+
+- Simple for requesters
+- Lower barrier to engagement
+- Fast for simple questions
+- Still rigorous for important decisions
+- Everything transparent (issues + ADRs)
+
+**Negative:**
+
+- Less formal than traditional governance
+- Board must identify when to create ADR
+
+**Implementation:**
+
+- Issue template: `architecture-question`
+- Process docs emphasize "ask early, ask often"
+- ADRs for precedent-setting decisions only
+
+## Alternatives Considered
+
+**Three-tier system:** Clear separation but high cognitive overhead
+
+**ADR-only:** Everything documented but too slow for simple questions
+
+**RFC-heavy:** Very formal but overkill for our multi-project context
+
+## References
+
+- [OME-NGFF RFC Process](https://ngff.openmicroscopy.org)
+- [ADR GitHub Repository](https://adr.github.io/)