|
1 | | -# Structural Explainability Annotation Standard |
| 1 | +# Annotations |
2 | 2 |
|
3 | 3 | <!-- |
4 | | -WHY: Defines the structured annotation vocabulary for documenting decisions. |
5 | | -WHY: Annotations make decisions explicit, scannable, and comparable across files and repositories. |
6 | | -OBS: Version 1.0, December 2025. |
| 4 | +WHY: This repository uses the Structural Explainability Annotation Standard |
| 5 | +to document decisions, constraints, and alternatives directly alongside |
| 6 | +code and configuration. |
7 | 7 | --> |
8 | 8 |
|
9 | | -Structured annotations document decisions, constraints, alternatives, and observations |
10 | | -directly alongside code and configuration. |
11 | | - |
12 | | -Annotations are **human-readable**, **machine-scannable**, and **non-enforcing by default**. |
13 | | -They explain _why something is the way it is_ without turning comments into executable policy. |
14 | | - |
15 | | -## Core Vocabulary |
16 | | - |
17 | | -Five annotations cover the majority of use cases. |
18 | | - |
19 | | -| Annotation | Purpose | Use | |
20 | | -| ---------- | ------------------------- | ----------------------------------- | |
21 | | -| `WHY` | Rationale | Explain intent or trade-offs | |
22 | | -| `OBS` | Observable fact | State current state or measurements | |
23 | | -| `REQ` | Requirement or constraint | Declare invariants | |
24 | | -| `ALT` | Alternative | Document other viable options | |
25 | | -| `CUSTOM` | Customization point | Flag values expected to change | |
26 | | - |
27 | | -`REQ` documents intent. It does not imply enforcement unless paired with tooling. |
28 | | - |
29 | | -## Extended Vocabulary |
30 | | - |
31 | | -Three additional annotations support governance-heavy or analytical contexts. |
32 | | - |
33 | | -| Annotation | Purpose | Use | |
34 | | -| ---------- | ------------------ | ---------------------------------------- | |
35 | | -| `MODEL` | Decision framework | Attribute reasoning to a method or model | |
36 | | -| `EVIDENCE` | Supporting data | Cite data underlying a decision | |
37 | | -| `ATTEST` | Verification | Record that validation occurred | |
38 | | - |
39 | | -Extended annotations are optional. Most repositories need only the core five. |
40 | | - |
41 | | -## Scoping |
42 | | - |
43 | | -Annotations apply at different scopes. |
44 | | - |
45 | | -### Default Scope |
46 | | - |
47 | | -Without qualification, an annotation applies to the **immediate next item** (line or block). |
48 | | - |
49 | | -```python |
50 | | -# WHY: Avoids circular import at module level. |
51 | | -from typing import TYPE_CHECKING |
52 | | -``` |
53 | | - |
54 | | -### Section Scope |
55 | | - |
56 | | -Use `=== SECTION NAME ===` markers to define logical boundaries within a file. |
57 | | - |
58 | | -```bash |
59 | | -# === Environment variables and secrets === |
60 | | - |
61 | | -# WHY: Never commit credentials or environment-specific configuration. |
62 | | -.env |
63 | | -.env.* |
64 | | -*.env |
65 | | - |
66 | | -# === LaTeX papers === |
67 | | - |
68 | | -# WHY: LaTeX build artifacts are regenerated on each compile. |
69 | | -*.aux |
70 | | -*.bbl |
71 | | -``` |
72 | | - |
73 | | -Annotations apply until the next section marker unless scoped more narrowly. |
74 | | - |
75 | | -Use the `-SECTION` suffix to make section scope explicit: |
76 | | - |
77 | | -```bash |
78 | | -# WHY-SECTION: All patterns below prevent committing generated artifacts. |
79 | | -``` |
80 | | - |
81 | | -Section markers are visual and semantic. The `=== ... ===` pattern is conventional but not enforced; any consistent delimiter works. |
82 | | - |
83 | | -### File Scope |
84 | | - |
85 | | -Use the `-FILE` suffix to apply an annotation to the entire document. |
86 | | - |
87 | | -```python |
88 | | -# WHY-FILE: Configuration for explainability and accountability tracking. |
89 | | -# OBS-FILE: Auto-generated; do not edit manually. |
90 | | -``` |
91 | | - |
92 | | -### Domain Scope |
93 | | - |
94 | | -Use **dot notation** to scope requirements to a domain. |
95 | | - |
96 | | -```python |
97 | | -# REQ.PYTHON: Use src/ layout for all packages. |
98 | | -# REQ.UNIVERSAL: Include .gitignore in all repositories. |
99 | | -``` |
100 | | - |
101 | | -Common domain scopes: |
102 | | - |
103 | | -| Scope | Applies to | |
104 | | -| ----------- | -------------------------------- | |
105 | | -| `UNIVERSAL` | All professional repositories | |
106 | | -| `PROJECT` | This specific project | |
107 | | -| `PYTHON` | Python projects | |
108 | | -| `RUST` | Rust projects | |
109 | | -| `LATEX` | LaTeX documents | |
110 | | -| `CI` | Continuous integration workflows | |
111 | | - |
112 | | -Dot notation is syntactic sugar. `REQ.PYTHON` is equivalent to `REQ[scope=python]`. |
113 | | - |
114 | | -### Arbitrary Scope |
115 | | - |
116 | | -Use **bracket notation** for scopes not covered by dot sugar. |
117 | | - |
118 | | -```yaml |
119 | | -# REQ[scope=nwmsu-courses]: All student repos must include acknowledgement when generative AI tools are used. |
120 | | -# REQ[scope=civic-interconnect]: Adapters must not define new entity kinds. |
121 | | -``` |
122 | | - |
123 | | -General form: `ANNOTATION[key=value]` or `ANNOTATION[value]` (shorthand for `scope=value`). |
124 | | - |
125 | | -### Scope Precedence |
126 | | - |
127 | | -Narrower scope overrides broader scope. `REQ.PROJECT` overrides `REQ.UNIVERSAL` for the same concern. |
128 | | - |
129 | | -## Syntax by Language |
130 | | - |
131 | | -Annotations use the same keywords across file types. Only comment syntax differs. |
132 | | - |
133 | | -| File Type | Syntax | |
134 | | -| ----------------------------------- | --------------------------- | |
135 | | -| Python, YAML, TOML, shell | `# WHY: Explanation` | |
136 | | -| HTML, Markdown, XML | `<!-- WHY: Explanation -->` | |
137 | | -| JavaScript, TypeScript, C, Rust, Go | `// WHY: Explanation` | |
138 | | -| CSS | `/* WHY: Explanation */` | |
139 | | -| LaTeX | `% WHY: Explanation` | |
140 | | - |
141 | | -## Machine Readability |
142 | | - |
143 | | -Annotations are designed to be scannable by tooling. |
144 | | - |
145 | | -### Core Pattern |
146 | | - |
147 | | -```regex |
148 | | -(WHY|OBS|REQ|ALT|CUSTOM|MODEL|EVIDENCE|ATTEST) |
149 | | -``` |
150 | | - |
151 | | -### With Scope |
152 | | - |
153 | | -```regex |
154 | | -(WHY|OBS|REQ|ALT|CUSTOM)(\.[A-Z]+|\[[^\]]+\])?(-FILE)?:\s*(.+) |
155 | | -``` |
156 | | - |
157 | | -### By Comment Style |
158 | | - |
159 | | -```python |
160 | | -# Python / YAML / TOML / shell |
161 | | -r'#\s*(WHY|OBS|REQ|ALT|CUSTOM)(\.[A-Z_]+|\[[^\]]+\])?(-FILE)?:\s*(.+)' |
162 | | - |
163 | | -# HTML / Markdown / XML |
164 | | -r'<!--\s*(WHY|OBS|REQ|ALT|CUSTOM)(\.[A-Z_]+|\[[^\]]+\])?(-FILE)?:\s*(.+?)\s*-->' |
165 | | - |
166 | | -# JavaScript / C-style |
167 | | -r'//\s*(WHY|OBS|REQ|ALT|CUSTOM)(\.[A-Z_]+|\[[^\]]+\])?(-FILE)?:\s*(.+)' |
168 | | -``` |
169 | | - |
170 | | -Tooling is optional. Annotations work without it. |
171 | | - |
172 | | -## Theoretical Basis |
173 | | - |
174 | | -This standard implements concepts from the Structural Explainability framework. |
175 | | - |
176 | | -| Annotation | CEE Concept | |
177 | | -| ---------- | -------------- | |
178 | | -| `WHY` | Explanation | |
179 | | -| `OBS` | Observation | |
180 | | -| `EVIDENCE` | Evidence set | |
181 | | -| `MODEL` | Decision model | |
182 | | -| `ATTEST` | Verification | |
183 | | - |
184 | | -`REQ`, `ALT`, and `CUSTOM` are pragmatic extensions for engineering use. |
185 | | -They document constraints and variation points that support explainability |
186 | | -but do not map directly to CEE's formal structure. |
187 | | - |
188 | | -## Examples |
189 | | - |
190 | | -### Configuration file (.editorconfig) |
191 | | - |
192 | | -```ini |
193 | | -# REQ.UNIVERSAL: All professional repositories MUST include .editorconfig. |
194 | | -# WHY: Establish cross-editor baseline so diffs stay clean. |
195 | | -# ALT: Omit ONLY if formatting enforced equivalently by CI. |
196 | | -# CUSTOM: Adjust indent_size if organizational standards differ. |
197 | | - |
198 | | -root = true |
199 | | - |
200 | | -[*] |
201 | | -# WHY: Normalize line endings across Windows, macOS, and Linux. |
202 | | -end_of_line = lf |
203 | | -charset = utf-8 |
204 | | - |
205 | | -# WHY: Newline at EOF avoids noisy diffs and tool warnings. |
206 | | -insert_final_newline = true |
207 | | -``` |
208 | | - |
209 | | -### Build configuration (pyproject.toml) |
210 | | - |
211 | | -```toml |
212 | | -# REQ.PYTHON: Python projects MUST include pyproject.toml as single source of truth. |
213 | | -# WHY: Centralizes metadata and configuration for reproducibility. |
214 | | - |
215 | | -[project] |
216 | | -name = "example" # CUSTOM: Update to match your package. |
217 | | -version = "0.1.0" # CUSTOM: Update as needed. |
218 | | - |
219 | | -[tool.ruff.lint] |
220 | | -select = [ |
221 | | - "E", # REQ: Basic syntax and structural correctness |
222 | | - "F", # REQ: Undefined names and unused imports |
223 | | - # "N", # ALT: Naming conventions (enable if enforcing naming policy) |
224 | | -] |
225 | | -``` |
226 | | - |
227 | | -### Source code (Python) |
228 | | - |
229 | | -```python |
230 | | -# WHY-FILE: Adapter for EU transparency register data. |
231 | | -# OBS: Schema version 2.3, last updated 2025-01. |
232 | | - |
233 | | -# WHY: Deferred import avoids circular dependency. |
234 | | -from typing import TYPE_CHECKING |
235 | | - |
236 | | -if TYPE_CHECKING: |
237 | | - from cee.core import Exchange |
238 | | - |
239 | | -def validate(record: dict) -> bool: |
240 | | - # REQ: All records must include source jurisdiction. |
241 | | - # EVIDENCE: See EP Section 4.2 for provenance requirements. |
242 | | - return "jurisdiction" in record |
243 | | -``` |
244 | | - |
245 | | -## Adoption |
246 | | - |
247 | | -### When to annotate |
248 | | - |
249 | | -- When a decision matters and future readers might ask why |
250 | | -- When alternatives exist and the choice is non-obvious |
251 | | -- When constraints are intentional, not accidental |
252 | | -- When customization is expected |
253 | | - |
254 | | -### When not to annotate |
255 | | - |
256 | | -- To restate what the code obviously does |
257 | | -- To replace proper documentation |
258 | | -- To enforce style (use linters) |
259 | | -- On every line (annotations are signal; overuse is noise) |
260 | | - |
261 | | -Value lies in **clarity**, not quantity. |
262 | | - |
263 | | -## Governance |
264 | | - |
265 | | -This standard is maintained at: |
| 9 | +This repository uses the annotation standard defined at: |
266 | 10 | <https://github.com/structural-explainability/.github/blob/main/ANNOTATIONS.md> |
267 | | - |
268 | | -Changes to the core vocabulary require consideration of downstream adopters. |
269 | | -Extended vocabulary and scoping mechanisms may evolve with use. |
0 commit comments