spec: add global surface IA contract

2026-06-10 22:17:02 +02:00 · 2026-06-10 22:17:02 +02:00 · 4bd6a521c4
commit 4bd6a521c4
parent 54eb8ca065
12 changed files with 1213 additions and 0 deletions
--- a/specs/370-global-surface-information-architecture-contract/artifacts/copy-and-terminology-rules.md
+++ b/specs/370-global-surface-information-architecture-contract/artifacts/copy-and-terminology-rules.md
@ -0,0 +1,99 @@
+# Copy And Terminology Rules
+
+Verification level: derived from existing implementation using existing repo vocabulary, constitution provider-boundary rules, and Spec 368 findings.
+
+## Default Voice
+
+- Lead with what the state means.
+- Use action-oriented copy.
+- Prefer stable platform nouns.
+- Avoid implementation-first language in primary UI copy.
+- Use technical words only where the audience and surface type require them.
+
+## Preferred Platform Terms
+
+- Workspace
+- Managed Environment
+- Provider Connection
+- Governed Subject
+- Operation
+- Evidence
+- Review
+- Finding
+- Governance
+- Diagnostics
+
+## Provider-Specific Terms
+
+Provider-specific terms are allowed when the surface is provider-owned or diagnostic, or when the term names an external product reality the operator must understand.
+
+Provider-specific terms should not become platform-core labels for generic surfaces.
+
+Examples to demote on non-diagnostic surfaces:
+
+- raw Graph payload
+- tenant ID
+- workspace ID
+- managed environment ID
+- API object ID
+- normalization lineage
+- provider response body
+
+## Status / Reason / Impact / Action Copy
+
+Good structure:
+
+- Status: current state.
+- Reason: why this is the state.
+- Impact: why it matters.
+- Primary action: what the user should do next.
+
+Avoid:
+
+- "Healthy" without explaining why that matters.
+- "Pending" without owner or next action.
+- "Failed" without likely cause or next check.
+- "View details" as the only action when a clearer action exists.
+
+## Customer-Safe Copy
+
+Customer/auditor surfaces should use:
+
+- outcome
+- evidence basis
+- limitation
+- accepted risk
+- review pack
+- exported report
+- next review or handoff action
+
+They should avoid by default:
+
+- internal run IDs
+- raw provider IDs
+- fingerprints
+- debug labels
+- internal reason families
+- stack traces
+- raw JSON
+
+## Action Labels
+
+Use `Verb + Object` where possible.
+
+Examples:
+
+- Review findings
+- Open evidence
+- Download review pack
+- Start restore preview
+- Open diagnostics
+- Check permissions
+
+Avoid primary labels that are only scope terms:
+
+- Workspace
+- Tenant
+- Environment
+
+Use scope words as secondary context unless the object being acted on is truly the scope.
--- a/specs/370-global-surface-information-architecture-contract/artifacts/follow-up-spec-map.md
+++ b/specs/370-global-surface-information-architecture-contract/artifacts/follow-up-spec-map.md
@ -0,0 +1,43 @@
+# Follow-up Spec Map
+
+Verification level: derived from existing implementation using Spec 368 recommendations, Spec 369 deferrals, and the user-provided Spec 370 draft.
+
+## Explicitly Deferred From Spec 370
+
+| Follow-up | Why Deferred | Suggested Boundary |
+|---|---|---|
+| Backup Set View decision-first productization | Restore-critical runtime UI change; should consume contract after docs are reviewed. | Existing Backup Set view only, no restore engine changes. |
+| OperationRun View metadata/proof separation polish | OperationRun surfaces were recently changed by Specs 358-367; avoid immediate broad reopening. | Run detail hierarchy only, reuse OperationRun UX contract. |
+| Customer/Auditor Surface Safety Pass | Customer-facing surfaces need careful browser and text review. | Customer Review Workspace, Environment Review, Review Pack, Stored Report, Evidence Snapshot reachability. |
+| Diagnostic Surface Separation | Needs fixture/auth work for Required Permissions/System/Evidence Snapshot. | Diagnostics pages and access paths only. |
+| Provider Connections readiness productization | Runtime configuration surface change near credentials and permissions. | Provider readiness summary and action hierarchy only. |
+| Target mock/example per archetype | Spec 368 Candidate A named this as useful, but Spec 370 v1 is limited to source-evidence-backed review rules and avoids creating target imagery. | Later design/spec package only, after the IA contract is accepted. |
+| UI Bloat Regression Guard v1 | Automation could be brittle before the contract is proven by consumers. | One bounded guard after another UI spec consumes this contract. |
+| Docs/product publication | May create duplicate source of truth too early. | Publish only after review or second consuming spec proves stable location is needed. |
+
+## Out-of-Scope Runtime Pages
+
+- Baseline Profile View
+- Backup Set View
+- OperationRun View
+- Restore Run View
+- Restore Create Wizard
+- Operations Hub
+- Environment Dashboard
+- Customer Review Workspace
+- Provider Connections
+- Environment Diagnostics
+- Required Permissions
+- Evidence Snapshot
+- System panel
+
+## Promotion Rule
+
+A follow-up may be promoted when it has:
+
+- source evidence;
+- a bounded surface list;
+- no hidden adjacent page refactors;
+- RBAC and isolation impact stated;
+- destructive/high-impact action safety preserved;
+- test lane and browser/manual smoke need stated.
--- a/specs/370-global-surface-information-architecture-contract/artifacts/page-assessment-checklist.md
+++ b/specs/370-global-surface-information-architecture-contract/artifacts/page-assessment-checklist.md
@ -0,0 +1,70 @@
+# Page Assessment Checklist
+
+Use this checklist when a future spec adds, removes, renames, or materially changes a reachable UI surface.
+
+## Applicability
+
+- [ ] The future spec states whether UI Surface Impact exists.
+- [ ] If no UI surface impact exists, the future spec gives one concise rationale and does not complete unnecessary page-report work.
+- [ ] If a reachable UI surface changes, the future spec names the route/page/action/state and updates or explicitly marks UI audit coverage.
+
+## Classification
+
+- [ ] Surface type is one of the Spec 370 surface types.
+- [ ] Audience type is declared.
+- [ ] Scope type is declared.
+- [ ] Repo-truth level is labeled with a verification class.
+- [ ] The surface has one primary user question.
+
+## First Viewport
+
+- [ ] Header answers where the user is.
+- [ ] One primary status is visible.
+- [ ] Reason and impact are visible when actionability depends on them.
+- [ ] One dominant next action is visible when a safe action exists.
+- [ ] Secondary actions do not compete with the dominant action.
+- [ ] Zero/no-attention metrics are suppressed unless they prove the state.
+- [ ] Raw IDs, provider payload terms, operation internals, and debug labels are absent by default unless the page is diagnostic/system/support.
+
+## Content Placement
+
+- [ ] Main content carries the page's primary decision or workflow answer.
+- [ ] Sidebar/aside carries secondary context and metadata.
+- [ ] Technical details are collapsed or secondary by default.
+- [ ] Evidence area is distinct from diagnostics.
+- [ ] Later sections add proof/detail instead of repeating the same decision summary.
+
+## Customer And Auditor Safety
+
+- [ ] Customer/auditor default paths avoid raw JSON, internal IDs, fingerprints, raw operation links, debug labels, and internal reason ownership.
+- [ ] Evidence readiness, limitations, captured-at timing, and export/handoff action are clear.
+- [ ] Support/raw detail is collapsed, lower-priority, or capability-gated.
+
+## Diagnostic Surfaces
+
+- [ ] Diagnostic pages lead with what failed.
+- [ ] Likely cause is stated when known.
+- [ ] Next check or operator action is visible.
+- [ ] Related evidence and operation links are present when available.
+- [ ] Raw detail is structured, not dumped as the primary page answer.
+
+## Review Outcome
+
+Choose one review outcome:
+
+- [ ] `blocker`
+- [ ] `strong-warning`
+- [ ] `documentation-required-exception`
+- [ ] `acceptable-special-case`
+
+Choose one workflow outcome:
+
+- [ ] `keep`
+- [ ] `split`
+- [ ] `document-in-feature`
+- [ ] `follow-up-spec`
+- [ ] `reject-or-split`
+
+## Notes
+
+Use `document-in-feature` for contained deviations. Use `follow-up-spec` when drift is recurring or structural. Do not rewrite completed historical specs to retrofit this checklist.
--- a/specs/370-global-surface-information-architecture-contract/artifacts/source-audit-summary.md
+++ b/specs/370-global-surface-information-architecture-contract/artifacts/source-audit-summary.md
@ -0,0 +1,46 @@
+# Source Audit Summary
+
+Verification level: repo-verified for file presence, browser-verified where Spec 368 screenshots or browser notes state browser evidence, derived from existing implementation where this package summarizes audit findings.
+
+## Primary Inputs
+
+| Source | Availability | Verification Class | Use In Spec 370 |
+|---|---|---|---|
+| `specs/368-platform-ui-signal-to-noise-browser-audit/audit.md` | available | repo-verified | Executive summary, page counts, top findings, refactor priority, maturity score |
+| `specs/368-platform-ui-signal-to-noise-browser-audit/findings.md` | available | repo-verified | Detailed bloat and page findings |
+| `specs/368-platform-ui-signal-to-noise-browser-audit/recommendations.md` | available | repo-verified | Global UI rule seed |
+| `specs/368-platform-ui-signal-to-noise-browser-audit/page-scorecard.csv` | available | repo-verified | Surface examples and scoring context |
+| `specs/368-platform-ui-signal-to-noise-browser-audit/page-inventory.csv` | available | repo-verified | Route/surface inventory context |
+| `specs/368-platform-ui-signal-to-noise-browser-audit/spec-candidates.md` | available | repo-verified | Candidate A source |
+| `specs/368-platform-ui-signal-to-noise-browser-audit/artifacts/raw/browser-notes.md` | available | repo-verified | Browser pass context and limitations |
+| `specs/368-platform-ui-signal-to-noise-browser-audit/artifacts/screenshots/` | available | browser-verified where screenshots captured pages | Examples and before-state evidence |
+
+## Audit Baseline
+
+- Audit date: 2026-06-09.
+- Pages discovered: 100 repo-verified UI routes.
+- Pages browser-audited: 19.
+- Screenshots available: 43.
+- Blocked or inaccessible pages: 4.
+- Overall platform UI maturity score: 3.6/5 across reachable browser-scored pages.
+
+## Top Repeating Patterns
+
+- Decision content competes with technical metadata.
+- Zero/no-attention metrics remain visible even when the page already states no action is needed.
+- Evidence, diagnostics, and operation internals are not always visually separated.
+- Provider readiness and required action can require inference from technical table columns.
+- Customer/auditor surfaces are mostly safe but can be dense.
+- Diagnostic surfaces need stronger first-block guidance.
+
+## Source Limitations
+
+| Input | Verification Class | Handling |
+|---|---|---|
+| Evidence Snapshot detail browser state | `not available` | Do not infer customer/auditor evidence-surface quality from the blocked page. |
+| Required Permissions browser state | `not available` | Keep configuration-surface recommendations generic until fixture/auth access is fixed. |
+| System dashboard browser state | `not available` | Treat system-surface findings as blocked source evidence, not browser-scored truth. |
+| System operations browser state | `not available` | Treat system-surface findings as blocked source evidence, not browser-scored truth. |
+| Target mock/example per archetype | `deferred` | Keep target imagery and archetype mockups for a later approved design/spec package. |
+
+Spec 370 must not invent conclusions for `not available` inputs. Future specs may promote a deferred item only with fresh source evidence and bounded scope.
--- a/specs/370-global-surface-information-architecture-contract/artifacts/surface-contract.md
+++ b/specs/370-global-surface-information-architecture-contract/artifacts/surface-contract.md
@ -0,0 +1,175 @@
+# Global Surface Information Architecture Contract v1
+
+Verification level: derived from existing implementation using Spec 368 browser-verified audit findings plus repo-verified existing surface patterns.
+
+## Principle
+
+Decision first. Diagnostics second. Evidence third. Technical metadata only on demand.
+
+Practical reading: the decision layer may show evidence availability or evidence basis because that is part of the decision. Diagnostic disclosure follows the primary decision, full evidence/proof remains distinct from diagnostics, and raw technical metadata stays on demand.
+
+This contract is a documentation and review artifact. It does not define a runtime framework, component library, presenter layer, static guard, or new persisted truth.
+
+It is subordinate to the project constitution, product standards, operator UX standards, enterprise UI standards, action surface contract, and runtime `ActionSurfaceType` enum. The IA review language in this package must not be used as a replacement for those canonical standards.
+
+## Verification Labels
+
+Future specs that use this contract must label surface facts with one of these verification classes:
+
+- `repo-verified`: confirmed in code, routes, tests, configs, or existing artifacts.
+- `browser-verified`: confirmed through browser pass or screenshot.
+- `derived from existing implementation`: logically derived from current implementation but not explicit product rule.
+- `foundation-real`: technical foundation exists but is not yet customer/operator-safe product surface.
+- `plausible`: sensible but not asserted as fact.
+- `not verified`: not checked.
+- `not available`: missing or unreachable.
+- `deferred`: explicitly later scope.
+
+Do not treat a plausible or deferred rule as implementation truth. Do not invent conclusions for unavailable browser evidence.
+
+## First-Viewport Contract
+
+Every decision-relevant surface should answer these questions before metadata:
+
+1. Where am I?
+2. What is the current state?
+3. Why is this the state?
+4. Why does it matter?
+5. What should I do next?
+6. What objects are affected?
+7. What evidence supports the claim?
+
+Default-visible structure:
+
+- Status
+- Reason
+- Impact
+- Primary next action
+- Affected objects
+- Evidence availability
+
+On demand:
+
+- Diagnostics
+- Operation internals
+- Raw IDs
+- Exact timestamps
+- Provider payloads
+- Raw logs
+- Normalization lineage
+- Technical counters
+
+## Header / First Viewport
+
+Allowed:
+
+- Entity title and human-readable entity type
+- One primary status
+- One reason or impact sentence
+- One primary action
+- At most two secondary actions when they are genuinely useful
+- Critical blocker or warning if current
+- Scope chip when needed for safety or disambiguation
+- Readiness badge when it changes operator action
+
+Disallowed by default:
+
+- Multiple repeated status badges
+- Raw IDs
+- Long technical names without a human label
+- Debug/provider payload terms
+- Multiple equally prominent actions
+- Zero metric cards
+- Full lifecycle/timing detail
+- Notification replay that pushes the page question down
+
+## Main Content
+
+Main content carries the primary answer for the page's job.
+
+Examples:
+
+- Backup Set: included items, restore usability, degraded/current-item exceptions when present.
+- Finding: risk, reason, affected object, owner, accepted-risk state, next action.
+- OperationRun: outcome, actionability, blocker/failure reason, affected objects, related evidence/diagnostic links.
+- Customer Review Workspace: review outcome, findings requiring decision, accepted risks, evidence/report pack availability, limitations.
+- Provider Connections: readiness, blocker reason, required action, affected workspaces/environments.
+
+Main content must not become a metadata drawer.
+
+## Sidebar / Aside
+
+Allowed:
+
+- Created/updated timestamps
+- Created by
+- Operation reference
+- Workspace/environment context
+- Source type
+- Plan/billing context where relevant
+- Last sync / last evaluated
+- Retention or disclosure level
+
+Rule: sidebar data may help orientation, but must never displace the decision.
+
+## Technical Details
+
+Collapsed by default except on explicit diagnostic or system-support surfaces.
+
+Contains:
+
+- Internal IDs
+- Raw provider IDs
+- Provider payload snippets
+- Normalization lineage
+- Operation context JSON
+- Exact timestamps
+- Debug labels
+- Technical counters
+- Raw logs
+- Stack traces
+- Advanced permission data
+
+Customer/auditor default paths must not expose raw internals. If technical detail is available to authorized operators/support users, label it in customer-safe language and gate or collapse it appropriately.
+
+## Evidence Area
+
+Evidence is not diagnostics.
+
+Evidence area shows:
+
+- Evidence type
+- Subject
+- Captured at
+- Customer-safe readiness
+- Limitations
+- Export/download action
+- Related review/report
+
+Evidence must be reachable and explain its limitations, but must not mix with raw logs, debug payloads, or runtime metadata.
+
+## Zero-Metric Suppression
+
+Suppress zero cards or no-attention metrics when the primary decision already says no action is needed.
+
+Keep zero metrics visible only when:
+
+- zero is the proof of the current decision;
+- the metric is needed for audit/compliance interpretation;
+- the operator must compare it with a non-zero adjacent metric;
+- the page is explicitly diagnostic or system-support-oriented.
+
+## Duplicate-Truth Control
+
+One first-viewport block owns the current decision. Later sections add evidence or detail; they should not restate the same status, reason, impact, and next action as peers.
+
+Allowed duplication:
+
+- Short status chips inside rows when rows represent independent objects.
+- Evidence labels that prove the decision.
+- Audit trail entries that record historical states.
+
+Disallowed duplication:
+
+- Multiple first-viewport cards that repeat the same "ready", "healthy", "no action", or "blocked" message.
+- Separate action panels that compete with the primary action without new decision context.
--- a/specs/370-global-surface-information-architecture-contract/artifacts/surface-type-matrix.md
+++ b/specs/370-global-surface-information-architecture-contract/artifacts/surface-type-matrix.md
@ -0,0 +1,60 @@
+# Surface Type Matrix
+
+Verification level: derived from existing implementation using Spec 368 audit evidence and existing repo UI taxonomy.
+
+Terminology boundary: the classes below are Spec 370 IA review classes for documentation review. They are not runtime `ActionSurfaceType` values, do not replace the repo's UI/UX Surface Classification or UI Action Matrix, and do not override canonical product/UI standards.
+
+## Verification Classes
+
+| Class | Meaning |
+|---|---|
+| `repo-verified` | Confirmed in code, routes, tests, configs, or existing artifacts. |
+| `browser-verified` | Confirmed through browser pass or screenshot. |
+| `derived from existing implementation` | Logically derived from current implementation but not explicit product rule. |
+| `foundation-real` | Technical foundation exists but is not yet customer/operator-safe product surface. |
+| `plausible` | Sensible but not asserted as fact. |
+| `not verified` | Not checked. |
+| `not available` | Missing or unreachable. |
+| `deferred` | Explicitly later scope. |
+
+## Spec 370 IA Review Classes
+
+| IA Review Class | Purpose | Primary User Question | Allowed First Viewport | Disallowed First Viewport | Required Primary Signal | Next-Action Model | Evidence Expectation | Diagnostics Expectation | Metadata Placement | Customer Safety | Spec 368 Examples |
+|---|---|---|---|---|---|---|---|---|---|---|---|
+| `decision_surface` | Make one governance or readiness decision decidable. | Is this good, blocked, risky, or ready? | status, reason, impact, one next action, evidence basis | raw IDs, lineage-first layout, repeated badges | decision state | one dominant action | visible evidence basis | linked/collapsed | sidebar/details | medium to high | Baseline Profile, Baseline Compare |
+| `operator_surface` | Help operators triage and act. | What needs attention now? | prioritized items, blockers, active work, next action | zero-card spam, equal-weight metrics | actionability | prioritized queue/action | linked evidence | secondary | sidebar/details | medium | Environment Dashboard, Operations Hub |
+| `workflow_surface` | Guide a multi-step operation safely. | Where am I in the flow and what is safe next? | step state, validation, preview, confirmation | raw payloads before preview, unclear mutation scope | current step/safety | guided primary action | preview/proof links | on demand | aside/details | medium | Restore Create Wizard, Restore Run |
+| `customer_surface` | Give customer-safe governance consumption. | What is the outcome and what should we know? | outcome, limitations, evidence/report availability, accepted risks | debug terms, internal IDs, operation internals | customer-safe outcome | review/download/handoff | explicit and safe | hidden/collapsed | hidden/aside | high | Customer Review Workspace |
+| `auditor_surface` | Prove evidence and disclosure state. | What supports the claim and what are the limitations? | evidence type, subject, captured at, limitations, export | raw runtime logs as proof, unsupported claims | evidence readiness | inspect/export | primary | secondary | aside/details | high | Review Pack, Stored Report |
+| `evidence_surface` | Present evidence as proof. | What was captured and can it be trusted? | subject, capture time, readiness, limitation | unrelated operation internals | evidence state | inspect/export/link review | primary | separated | sidebar/details | high | Evidence Snapshot was blocked |
+| `diagnostic_surface` | Diagnose failure or missing readiness. | What failed, likely why, what to check next? | failure, likely cause, next check, related run/evidence | vague health-only cards | failure/actionability | next check | linked | primary but structured | details allowed | low to medium | Environment Diagnostics |
+| `configuration_surface` | Manage readiness/configuration safely. | Is this configured and what is missing? | readiness, blocker, required action, affected scope | capability columns as only signal | readiness | fix/open required setup | secondary | secondary | table/details | medium | Provider Connections, Required Permissions blocked |
+| `system_surface` | Support platform/system operations. | What platform state needs action? | impact, admin action, operational state | raw internals without impact | operational impact | admin/support action | linked where relevant | allowed | details/table | low customer safety | System panel blocked |
+| `portfolio_surface` | Compare or prioritize across workspaces/environments. | Where should I focus? | aggregate attention, ranked risk, filters | unscoped totals without meaning | prioritized signal | drill down | summarized | linked | aside/details | medium | Portfolio surfaces not central in Spec 368 |
+| `support_surface` | Help support investigate with permission. | What context explains the case? | case state, affected scope, safe diagnostics | customer-unsafe raw data without gating | support actionability | inspect/export/handoff | linked | allowed/gated | details | low to medium | Support diagnostic patterns |
+| `unknown` | Temporary classification for unreviewed surfaces. | What is this page for? | minimal title and no false claims | claiming maturity without review | unknown | review required | unknown | unknown | unknown | unknown | Unclassified future pages |
+
+## Audience Types
+
+| Audience | Needs To Decide | Must Not Be Forced To Understand | Technical Depth | Language Style | Evidence Expectation | Diagnostics Expectation | Action Model |
+|---|---|---|---|---|---|---|---|
+| `operator` | what needs action and what is safe next | provider payloads, raw IDs, internal reason ownership | moderate on demand | direct, action-oriented | linked and summarized | secondary | one dominant action |
+| `customer` | governance outcome, limitation, handoff/download | internal diagnostics, OperationRun internals, raw JSON | low | customer-safe, non-debug | explicit | hidden/collapsed | review/download/handoff |
+| `auditor` | proof, scope, limitation, retention/disclosure | runtime implementation details unless evidence-relevant | low to moderate | precise, evidence-first | primary | separated | inspect/export |
+| `platform_admin` | platform operational impact and admin action | tenant customer narratives unless needed | high | operational, impact-led | linked | allowed | admin/support action |
+| `support` | likely cause, next check, safe context | unrelated product marketing/copy | high with gating | diagnostic but safe | linked | primary | inspect/escalate/handoff |
+| `developer` | implementation detail during internal troubleshooting | customer decision copy as only signal | high | technical | optional | primary | debug/fix |
+| `mixed` | audience-specific current decision | all possible audience details at once | layered | neutral with sections | layered | layered | audience-aware |
+| `unknown` | unknown | false specificity | minimal | cautious | unknown | unknown | classify first |
+
+## Scope Types
+
+| Scope | Rule |
+|---|---|
+| `workspace_scoped` | Workspace is primary platform context; show human workspace context, not raw `workspace_id`. |
+| `environment_scoped` | Environment/tenant is secondary domain context; make filter or target scope explicit. |
+| `tenant_scoped` | Tenant-owned data must remain workspace + tenant authorized; no cross-tenant leakage. |
+| `customer_scoped` | Customer surfaces explain scope in customer-safe terms, not internal IDs. |
+| `system_scoped` | System surfaces may be technical but still lead with impact and admin action. |
+| `mixed` | Mixed scope must be explained without overloading the header. |
+| `unknown` | Treat as review-required; do not expose raw IDs as a substitute for scope clarity. |
--- a/specs/370-global-surface-information-architecture-contract/artifacts/ui-bloat-patterns.md
+++ b/specs/370-global-surface-information-architecture-contract/artifacts/ui-bloat-patterns.md
@ -0,0 +1,50 @@
+# UI Bloat Pattern Registry
+
+Verification level: derived from existing implementation using Spec 368 audit findings and recommendations.
+
+## Pattern 1: Repeated Lifecycle Or Status Language
+
+- **Observed in**: Operations, Backup, Restore, Customer Review.
+- **Impact**: Dilutes the primary decision and makes healthy pages feel busy.
+- **Rule**: One first-viewport block owns status, reason, impact, and next action.
+- **Allowed exception**: row-level badges for independent rows.
+
+## Pattern 2: Zero Metric Card Spam
+
+- **Observed in**: Environment Dashboard, Operations Hub, Restore Run.
+- **Impact**: No-action states look like dashboards of warnings.
+- **Rule**: Suppress zero cards when the primary decision already says no action is needed.
+- **Allowed exception**: zero is itself proof or audit-significant.
+
+## Pattern 3: Technical Metadata In Main Content
+
+- **Observed in**: Backup Set, Baseline Profile, OperationRun.
+- **Impact**: Operators parse internals before the decision.
+- **Rule**: Move IDs, timing, normalization lineage, provider details, and operation context to sidebar or collapsed details.
+- **Allowed exception**: explicit diagnostic/system surface.
+
+## Pattern 4: Shell Chrome Density
+
+- **Observed in**: most captured admin/customer pages.
+- **Impact**: Page question is delayed below navigation, notification replay, and repeated context.
+- **Rule**: First viewport must keep the page's current question visible.
+- **Allowed exception**: critical active warning or blocking context.
+
+## Pattern 5: Evidence And Diagnostics Ambiguity
+
+- **Observed in**: Evidence Snapshot, Required Permissions, System Panel blocked/partial audit.
+- **Impact**: Reviewers cannot tell whether a claim is supported by evidence, diagnostics, or unverified runtime state.
+- **Rule**: Evidence proves claims; diagnostics explain failure. Keep them visually and verbally separate.
+- **Allowed exception**: support surfaces may show both, but still label them separately.
+
+## Pattern 6: Provider Readiness Inference
+
+- **Observed in**: Provider Connections list.
+- **Impact**: Operators infer readiness from capability/config columns instead of seeing a primary readiness decision.
+- **Rule**: Configuration surfaces lead with readiness, blocker reason, required action, and affected scope.
+
+## Pattern 7: Customer-Safe Surface Density
+
+- **Observed in**: Customer Review Workspace.
+- **Impact**: Good customer-safe content still demands too much scanning.
+- **Rule**: Customer/auditor first viewport shows outcome, limitation, evidence/report availability, accepted risks when relevant, and one handoff/review action.
--- a/specs/370-global-surface-information-architecture-contract/artifacts/validation-report.md
+++ b/specs/370-global-surface-information-architecture-contract/artifacts/validation-report.md
@ -0,0 +1,60 @@
+# Validation Report
+
+## Repo Safety Snapshot
+
+- Branch before Spec Kit execution: `platform-dev`
+- Branch after Spec Kit execution: `370-global-surface-information-architecture-contract`
+- Branch after review correction: `feat/370-global-surface-information-architecture-contract`
+- HEAD: `54eb8ca0`
+- Dirty files before Spec Kit execution: none
+- Staged files before Spec Kit execution: none
+- New untracked package after Spec Kit execution: `specs/370-global-surface-information-architecture-contract/`
+- Existing `specs/370-*` directories before creation: none
+
+## Source Artifact Availability
+
+- `specs/368-platform-ui-signal-to-noise-browser-audit/audit.md`: available
+- `specs/368-platform-ui-signal-to-noise-browser-audit/page-scorecard.csv`: available
+- `specs/368-platform-ui-signal-to-noise-browser-audit/findings.md`: available
+- `specs/368-platform-ui-signal-to-noise-browser-audit/recommendations.md`: available
+- `specs/368-platform-ui-signal-to-noise-browser-audit/spec-candidates.md`: available
+- `specs/368-platform-ui-signal-to-noise-browser-audit/artifacts/raw/browser-notes.md`: available
+- `specs/368-platform-ui-signal-to-noise-browser-audit/artifacts/screenshots/`: available
+- `docs/product/spec-candidates.md`: available
+- `docs/product/roadmap.md`: available
+
+## Command Notes
+
+- Spec Kit branch/spec setup: `./.specify/scripts/bash/create-new-feature.sh --json --number 370 --short-name global-surface-information-architecture-contract ...`
+- Plan setup: `./.specify/scripts/bash/setup-plan.sh --json`
+- Separate shell `tasks` and `analyze` scripts are not present in `.specify/scripts/bash/`; tasks and analysis follow repository templates/agent guidance.
+
+## Preparation Analysis
+
+- Spec Kit prerequisite check: PASS. `check-prerequisites.sh --json --require-tasks --include-tasks` resolved this feature directory and `tasks.md`.
+- Read-only cross-artifact analysis: PASS after bounded review corrections in Spec 370 artifacts only.
+- Findings fixed:
+  - Spec 370 IA review classes are explicitly bounded away from canonical product/UI standards and runtime `ActionSurfaceType` values.
+  - Branch metadata now follows the repo's `feat/<NNN>-<slug>` convention.
+  - Spec 368 Candidate A target mock/example artifacts are explicitly deferred.
+  - Final readiness wording is tied to completion of validation tasks instead of predeclared while tasks are unchecked.
+  - Verification class wording now uses `derived from existing implementation` instead of an unqualified `derived` label.
+  - `surface-contract.md` now defines the verification labels directly instead of relying only on the matrix.
+  - `source-audit-summary.md` now classifies blocked Spec 368 evidence as `not available` and target mock/example work as `deferred`.
+- Placeholder scan: PASS. The only placeholder-like match is the checklist sentence that says no clarification markers remain.
+- Trailing whitespace scan over `specs/370-global-surface-information-architecture-contract/`: PASS.
+- `git diff --check`: PASS.
+
+## Final Validation Snapshot
+
+- Current branch: `feat/370-global-surface-information-architecture-contract`
+- Base HEAD before final Spec 370 commit: `54eb8ca0`
+- Final delivery status: `specs/370-global-surface-information-architecture-contract/` is the only intended package for this branch and is tracked in the Spec 370 commit.
+- Runtime file changes: none.
+- Application test lane: N/A because the package is docs-only and does not change runtime behavior.
+- Browser smoke lane: N/A because no reachable UI surface, route, panel, action, Livewire interaction, or rendered page changed.
+- Remaining non-blocking question: whether a later approved spec should publish this contract under `docs/product/` after at least one additional consuming UI productization spec validates it.
+
+## Runtime Impact
+
+No application implementation has been performed. No runtime files, tests, migrations, routes, policies, Filament resources/pages, Livewire components, services, jobs, config, assets, or docs outside this spec package are modified.
--- a/specs/370-global-surface-information-architecture-contract/checklists/requirements.md
+++ b/specs/370-global-surface-information-architecture-contract/checklists/requirements.md
@ -0,0 +1,44 @@
+# Requirements Checklist: Spec 370 - Global Surface Information Architecture Contract v1
+
+**Purpose**: Validate that Spec 370 is complete, scoped, constitution-aligned, and ready for a later docs-only implementation/review step.
+**Created**: 2026-06-10
+**Feature**: `specs/370-global-surface-information-architecture-contract/spec.md`
+
+## Candidate Selection
+
+- [x] CHK001 Selected candidate exists in source material: user-provided Spec 370 draft and Spec 368 Candidate A.
+- [x] CHK002 No existing `specs/370-*` package was found before creation.
+- [x] CHK003 Related completed/validated specs are context only and are not modified.
+- [x] CHK004 Scope is the smallest viable slice: docs-only contract artifacts, no runtime UI changes.
+- [x] CHK005 Close alternatives are deferred instead of hidden inside Spec 370.
+
+## Spec Completeness
+
+- [x] CHK006 Spec has a clear problem statement and user-visible value.
+- [x] CHK007 Spec includes functional requirements, non-functional requirements, acceptance criteria, assumptions, risks, and open questions.
+- [x] CHK008 User stories are independently testable through artifact review.
+- [x] CHK009 Out-of-scope boundaries explicitly exclude application code, migrations, tests, routes, UI, assets, RBAC, and OperationRun changes.
+- [x] CHK010 No `[NEEDS CLARIFICATION]` markers remain.
+
+## Constitution Alignment
+
+- [x] CHK011 Proportionality review is included because the spec creates a review vocabulary and Markdown artifact set.
+- [x] CHK012 The spec avoids runtime abstractions, presenters, registries, component systems, or static guards.
+- [x] CHK013 UI-COV-001 no-impact decision is checked and explained.
+- [x] CHK014 RBAC, workspace/tenant isolation, provider boundary, audit/evidence, and OperationRun expectations are addressed for future consumers without changing runtime behavior.
+- [x] CHK015 Test governance explicitly states docs-only/manual review and no Pest/browser lane.
+
+## Artifact Readiness
+
+- [x] CHK016 `spec.md`, `plan.md`, and `tasks.md` exist.
+- [x] CHK017 Required artifacts are listed in the plan and acceptance criteria.
+- [x] CHK018 Tasks are ordered, small, verifiable, and limited to Spec 370 artifacts.
+- [x] CHK019 Follow-up candidates are mapped separately from primary scope.
+- [x] CHK020 Preparation can proceed without unresolved product decisions.
+- [x] CHK023 Spec 370 IA review classes are explicitly bounded away from canonical standards and runtime `ActionSurfaceType` values.
+- [x] CHK024 Target mock/example artifacts from Spec 368 Candidate A are explicitly deferred from this slice.
+
+## Review Outcome
+
+- [x] CHK025 Review outcome class: `acceptable-special-case` because the spec is docs-only but creates cross-surface vocabulary.
+- [x] CHK026 Workflow outcome: `keep` because the scope is bounded and explicitly excludes runtime implementation.
--- a/specs/370-global-surface-information-architecture-contract/plan.md
+++ b/specs/370-global-surface-information-architecture-contract/plan.md
@ -0,0 +1,210 @@
+# Implementation Plan: Spec 370 - Global Surface Information Architecture Contract v1
+
+**Branch**: `feat/370-global-surface-information-architecture-contract` | **Date**: 2026-06-10 | **Spec**: `specs/370-global-surface-information-architecture-contract/spec.md`
+**Input**: Feature specification from `specs/370-global-surface-information-architecture-contract/spec.md`
+
+## Summary
+
+Prepare a docs-only Global Surface Information Architecture Contract v1 under the Spec 370 package. The work formalizes the Spec 368 audit lessons into reusable review artifacts for future UI productization specs: decision-first hierarchy, surface/audience/scope classification, zero-metric suppression, evidence-vs-diagnostics separation, metadata placement, copy rules, and follow-up mapping. No application implementation is part of this plan.
+
+The contract is subordinate to `.specify/memory/constitution.md`, `docs/product/standards/`, `docs/ui/operator-ux-surface-standards.md`, `docs/ui/tenantpilot-enterprise-ui-standards.md`, `docs/ui/action-surface-contract.md`, and the runtime `ActionSurfaceType` enum. Spec 370 IA review classes are not runtime Action Surface values and do not publish a new canonical product standard in this slice.
+
+## Technical Context
+
+**Language/Version**: Markdown governance artifacts in a PHP 8.4 / Laravel 12 / Filament v5 / Livewire v4 repository.
+**Primary Dependencies**: Spec Kit templates and existing repo documentation. No package or runtime dependency changes.
+**Storage**: Markdown files under `specs/370-global-surface-information-architecture-contract/`.
+**Testing**: Manual artifact review and `git diff --check`. No Pest or browser test required because there is no runtime behavior change.
+**Validation Lanes**: docs-only/manual review.
+**Target Platform**: TenantPilot repo workflow.
+**Project Type**: Laravel monolith plus Spec Kit docs.
+**Performance Goals**: N/A.
+**Constraints**: No runtime code, migrations, assets, routes, policies, jobs, services, tests, or UI changes.
+**Scale/Scope**: One spec package and spec-local artifacts.
+
+## Candidate Selection Gate
+
+- **Selected candidate exists in source material**: yes, from the user-provided Spec 370 draft and Spec 368 Candidate A.
+- **Not already covered by active/completed spec**: yes. Spec 369 intentionally deferred the global contract, and no `specs/370-*` package existed before this run.
+- **Completed-spec guardrail**: Spec 368 is an audit/source artifact. Spec 369 is completed/validated and not modified. Existing completed specs are context only.
+- **Roadmap fit**: yes, aligned with the roadmap's UI and product maturity polish lane and decision-centered operating model.
+- **Smallest viable slice**: docs-only contract and checklist artifacts.
+- **Deferred adjacent work**: page runtime refactors, diagnostic fixture work, browser screenshot updates, target mock/examples per archetype, automation/static guards, and docs/product publication.
+- **Gate result**: PASS.
+
+## UI / Surface Guardrail Plan
+
+- **Guardrail scope**: no operator-facing surface change; docs-only guardrail package.
+- **Affected routes/pages/actions/states/navigation/panel/provider surfaces**: N/A.
+- **No-impact class**: docs-only.
+- **Native vs custom classification summary**: N/A for runtime. Future specs must prefer native Filament/shared primitives.
+- **Shared-family relevance**: status messaging, evidence/report viewers, diagnostics disclosure, dashboard signals, action hierarchy as review guidance only.
+- **State layers in scope**: none at runtime.
+- **Audience modes in scope**: defined for future review: operator, customer, auditor, platform_admin, support, developer, mixed, unknown.
+- **Decision/diagnostic/raw hierarchy plan**: decision-first, diagnostics-second, evidence-third, technical metadata on demand, with explicit evidence/diagnostics separation.
+- **Raw/support gating plan**: future customer/auditor surfaces must collapse or capability-gate raw/support detail by default.
+- **One-primary-action / duplicate-truth control**: future surfaces should expose one dominant next action and avoid duplicated first-viewport status/reason/impact.
+- **Handling modes by drift class or surface**: report-only in this spec; future deviations are `document-in-feature` or `follow-up-spec`.
+- **Repository-signal treatment**: report-only for this docs package.
+- **Special surface test profiles**: N/A.
+- **Required tests or manual smoke**: manual artifact review only.
+- **Exception path and spread control**: no runtime exceptions; any future exception must name the surface, audience, rule, reason, and containment path.
+- **Active feature PR close-out entry**: N/A.
+- **UI/Productization coverage decision**: No UI surface impact.
+- **Coverage artifacts to update**: none for this prep; future UI-changing specs update `docs/ui-ux-enterprise-audit/` as required.
+- **No-impact rationale**: only files in `specs/370-global-surface-information-architecture-contract/` are created/updated.
+- **Navigation / Filament provider-panel handling**: no provider or navigation changes.
+- **Screenshot or page-report need**: no new screenshots. Existing Spec 368 screenshots are source evidence.
+
+## Shared Pattern & System Fit
+
+- **Cross-cutting feature marker**: yes, docs-only.
+- **Systems touched**: no runtime systems. Context references include Spec 368 audit artifacts, Spec 336 baseline compare, Spec 344 customer review, Spec 369 Baseline Profile decision view, UI-COV-001, and existing shared interaction helpers.
+- **Shared abstractions reused**: no runtime abstraction. Future specs should reuse existing `BadgeCatalog`, `BadgeRenderer`, `ActionSurfaceDeclaration`, `OperationUxPresenter`, `OperationRunLinks`, `UiEnforcement`, and `WorkspaceUiEnforcement` where applicable.
+- **New abstraction introduced? why?**: no runtime abstraction. The documentation contract is necessary because the repeated issue is cross-surface review consistency, not missing code infrastructure.
+- **Why the existing abstraction was sufficient or insufficient**: Existing code helpers are sufficient for runtime semantics; they do not give future specs one product-information hierarchy to review against.
+- **Bounded deviation / spread control**: contract remains spec-local until a later approval decides whether to publish it under `docs/product/`. It must not be treated as an `ActionSurfaceType` extension or a replacement for existing standards.
+
+## OperationRun UX Impact
+
+- **Touches OperationRun start/completion/link UX?**: no.
+- **Central contract reused**: N/A.
+- **Delegated UX behaviors**: N/A.
+- **Surface-owned behavior kept local**: N/A.
+- **Queued DB-notification policy**: N/A.
+- **Terminal notification path**: N/A.
+- **Exception path**: none.
+
+## Provider Boundary & Portability Fit
+
+- **Shared provider/platform boundary touched?**: docs guidance only.
+- **Provider-owned seams**: provider payloads, provider IDs, permission internals, portal/API terminology, and Graph-specific diagnostics remain provider-owned/support detail.
+- **Platform-core seams**: workspace, managed environment, provider connection, governed subject, operation, evidence, diagnostics, customer-safe, support/raw.
+- **Neutral platform terms / contracts preserved**: yes.
+- **Retained provider-specific semantics and why**: Microsoft/Intune examples remain as source evidence because they are current implementation reality, but default contract language is provider-neutral.
+- **Bounded extraction or follow-up path**: future runtime provider-boundary exceptions are `document-in-feature` or `follow-up-spec`.
+
+## Constitution Check
+
+- Inventory-first: PASS / N/A. No inventory or snapshot truth changes.
+- Read/write separation: PASS. No write/change behavior is introduced.
+- Graph contract path: PASS / N/A. No Graph calls.
+- Deterministic capabilities: PASS / N/A. No capability derivation changes.
+- RBAC-UX and isolation: PASS. Future specs are required to preserve RBAC and deny-as-not-found semantics; this spec changes none.
+- Run observability and OperationRun: PASS / N/A. No OperationRun behavior.
+- Test governance: PASS. Docs-only lane is stated with no runtime test requirement.
+- Proportionality: PASS with explicit review because the spec creates documentation vocabulary and artifacts.
+- No premature abstraction: PASS. No runtime framework, component, presenter, registry, or guard is introduced.
+- Persisted truth: PASS. Spec-local Markdown artifacts only; no database truth.
+- Behavioral state: PASS. No runtime state/status/reason code family.
+- UI semantics: PASS with risk control. The contract stays as review guidance and avoids mandatory code architecture.
+- Shared pattern first: PASS. Future specs are instructed to reuse existing shared paths first.
+- Provider boundary: PASS. Provider-specific detail is kept out of platform-core default language.
+- UI/Productization coverage: PASS. Checked no-impact with rationale.
+- Filament v5 / Livewire v4: PASS. No runtime Filament/Livewire changes; future guidance references native/shared primitives.
+
+## Project Structure
+
+```text
+specs/370-global-surface-information-architecture-contract/
+├── spec.md
+├── plan.md
+├── tasks.md
+├── checklists/
+│   └── requirements.md
+└── artifacts/
+    ├── source-audit-summary.md
+    ├── surface-contract.md
+    ├── surface-type-matrix.md
+    ├── ui-bloat-patterns.md
+    ├── page-assessment-checklist.md
+    ├── copy-and-terminology-rules.md
+    ├── follow-up-spec-map.md
+    └── validation-report.md
+```
+
+No `data-model.md`, `contracts/`, `research.md`, or `quickstart.md` is required for this docs-only package unless a later reviewer asks for a separate publication decision.
+
+## Implementation Phases
+
+### Phase 0 - Source Evidence And Scope Lock
+
+- Confirm Spec 368 source artifacts exist and mark missing inputs as `not available`.
+- Confirm no existing Spec 370 package or branch was present before creation.
+- Lock the no-runtime-change boundary.
+
+### Phase 1 - Contract Artifacts
+
+- Draft the surface IA contract.
+- Document the canonical standards boundary and the fact that Spec 370 IA review classes are not runtime `ActionSurfaceType` values.
+- Draft the surface type, audience, and scope matrix.
+- Draft the UI bloat pattern registry.
+- Draft the page assessment checklist.
+- Draft copy and terminology rules.
+- Draft the follow-up spec map.
+- Explicitly defer Spec 368 Candidate A target mock/example artifacts from this slice.
+
+### Phase 2 - Consistency And Readiness
+
+- Ensure `spec.md`, `plan.md`, `tasks.md`, checklist, and artifacts agree.
+- Run Spec Kit prerequisite check with tasks.
+- Run read-only preparation analysis guidance.
+- Fix only Spec Kit artifacts if analysis finds bounded issues.
+- Run `git diff --check`.
+
+## Data Model
+
+N/A. No database tables, models, migrations, JSONB columns, indexes, or persisted runtime artifacts.
+
+## API / Contracts
+
+N/A. No HTTP API, OpenAPI contract, JSON schema, Graph contract, queue contract, or external integration changes.
+
+## UI / Filament Implications
+
+No current Filament resource/page/provider/panel changes.
+
+Future UI-changing specs should:
+
+- keep Filament v5 / Livewire v4 compatibility;
+- register panel providers only in `apps/platform/bootstrap/providers.php` when panel code changes;
+- keep global search disabled unless View/Edit page and scoping rules are safe;
+- keep destructive/high-impact actions on `->action(...)`, `->requiresConfirmation()`, server-side authorization, audit, and tests;
+- use native Filament/shared primitives first;
+- continue filling the repo's UI/UX Surface Classification and UI Action Matrix with canonical Action Surface classes, not Spec 370 IA review labels;
+- update `docs/ui-ux-enterprise-audit/` only when reachable UI surfaces change.
+
+## Test Strategy
+
+- No Pest, PHPUnit, browser, PostgreSQL, or frontend test lane is required for this docs-only preparation package.
+- Required validation:
+  - `./.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks`
+  - read-only preparation analysis across `spec.md`, `plan.md`, and `tasks.md`
+  - `git diff --check`
+- Future runtime specs that consume this contract must add focused Filament/Livewire/browser coverage only for the changed surface.
+
+## Rollout Considerations
+
+- No deploy impact.
+- No env var, migration, queue, scheduler, storage, cache, Graph, asset, or worker impact.
+- No `php artisan filament:assets` requirement because no Filament assets are registered.
+- A later docs/product publication step may be considered only after review.
+
+## Risk Controls
+
+- Keep contract artifacts spec-local.
+- Keep canonical standards and runtime Action Surface terminology authoritative.
+- Keep automation/static guard work out of scope.
+- Keep target mock/example artifacts out of scope unless a later spec approves them.
+- Label source evidence by verification class.
+- Require future deviations to be recorded in the active feature instead of silently forking UI language.
+- Do not edit completed Spec 368/369 artifacts.
+
+## Spec Readiness Gate
+
+- `spec.md`, `plan.md`, `tasks.md`: required.
+- `checklists/requirements.md`: required.
+- Contract artifacts: required.
+- Blocking open questions: none.
+- Runtime implementation risk: none in this package.
+- Later implementation scope: bounded docs-only finalization and optional review publication decision.
--- a/specs/370-global-surface-information-architecture-contract/spec.md
+++ b/specs/370-global-surface-information-architecture-contract/spec.md
@ -0,0 +1,291 @@
+# Feature Specification: Spec 370 - Global Surface Information Architecture Contract v1
+
+**Feature Branch**: `feat/370-global-surface-information-architecture-contract`
+**Created**: 2026-06-10
+**Status**: Draft
+**Input**: User-provided Spec 370 draft, Spec 368 Platform-wide UI Signal-to-Noise Browser Audit, and Spec 368 Candidate A.
+
+## Candidate Selection Summary
+
+- **Selected candidate**: Global Surface Information Architecture Contract v1.
+- **Source**: User-provided Spec 370 draft and `specs/368-platform-ui-signal-to-noise-browser-audit/spec-candidates.md` Candidate A.
+- **Why selected**: Spec 368 found recurring signal-to-noise issues across operations, backup, baseline, provider, diagnostic, and customer/auditor surfaces. The same pattern appears repeatedly: pages expose available data before the current decision, reason, impact, next action, and evidence basis. A docs-only contract is the smallest low-runtime-risk way to align later UI productization specs before more page-local refactors diverge.
+- **Roadmap relationship**: Supports the roadmap's UI and product maturity polish lane, especially the decision-centered operating model and surface/IA classification direction in `docs/product/roadmap.md`.
+- **Smallest viable slice**: Create a repo-anchored, docs-only contract under this spec package. It defines surface types, audience disclosure rules, header/main/sidebar/technical-details hierarchy, zero-metric suppression, verification classes, page assessment checklist, UI bloat patterns, and follow-up mapping. It does not change runtime UI.
+- **Canonical standards relationship**: Spec 370 is a spec-local IA review artifact, not a replacement for `.specify/memory/constitution.md`, `docs/product/standards/`, `docs/ui/operator-ux-surface-standards.md`, `docs/ui/tenantpilot-enterprise-ui-standards.md`, `docs/ui/action-surface-contract.md`, or the runtime `ActionSurfaceType` enum.
+- **Deferred close alternatives**:
+  - Core Operator View Surfaces Productization Pass: page-level runtime refactors remain follow-up specs.
+  - Customer/Auditor Surface Safety Pass: valuable, but should consume the global contract instead of defining a competing one.
+  - Diagnostic Surface Separation: valuable, but should consume the global contract and handle fixture/auth gaps separately.
+  - UI Bloat Regression Guard: deferred until the docs contract proves stable enough to automate safely.
+  - Target mock/example per archetype from Spec 368 Candidate A: deferred; this slice uses existing Spec 368 before-state evidence and does not create target imagery or mockups.
+  - Spec 369 Baseline Profile Decision View: already prepared and implemented/validated; not a prep target.
+- **Completed-spec guardrail**: No `specs/370-*` package existed before this run. Spec 368 is an audit/source artifact and is not modified. Spec 369 is completed/validated context and is not modified. Existing UI, action-surface, scope, and OperationRun specs are treated as historical context only.
+
+## Spec Candidate Check *(mandatory - SPEC-GATE-001)*
+
+- **Problem**: Operators, customer reviewers, auditors, and support users see inconsistent first-viewport hierarchy across TenantPilot surfaces. Several pages make users parse metadata, lifecycle fields, raw identifiers, repeated zero metrics, or technical diagnostics before understanding the decision.
+- **Today's failure**: New UI productization specs can solve the same problem differently page by page, creating parallel status language, inconsistent diagnostics disclosure, and duplicated decision summaries. A page may appear busy even when no action is needed, or technical truth may compete with the current operator decision.
+- **User-visible improvement**: Future surface work starts from one documented decision-first hierarchy: status, reason, impact, primary next action, affected objects, evidence availability, then diagnostics and technical metadata on demand.
+- **Smallest enterprise-capable version**: A docs-only contract and assessment checklist scoped to existing audit evidence. No runtime UI refactor, no new component library, no automated guard, no migration, and no broad design-system rebuild.
+- **Explicit non-goals**: No Filament page refactors, no new navigation, no CSS/theme work, no new Livewire components, no new persisted entities, no new policies/RBAC, no OperationRun behavior changes, no browser fixture fixes, and no broad static guard implementation.
+- **Permanent complexity imported**: One spec-local contract artifact set and a small vocabulary for verification class, surface type, audience type, and disclosure hierarchy. These are review rules, not runtime classes.
+- **Why now**: Spec 368 produced browser-verified cross-surface evidence, and Spec 369 intentionally deferred the global rule pack because a page-local fix was safer first. After the first page-local productization slice, the next small foundation is the shared contract that future slices can consume.
+- **Why not local**: The problem is repeated across multiple domains. Continuing page-local fixes without a shared contract risks five slightly different interpretations of decision-first UI and metadata disclosure.
+- **Approval class**: Workflow Compression.
+- **Red flags triggered**: New taxonomy/rule language and "foundation" risk. Defense: this spec is docs-only, uses existing audit evidence, does not create code abstractions, and explicitly defers automation until a separate approval.
+- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexität: 1 | Produktnähe: 2 | Wiederverwendung: 2 | **Gesamt: 11/12**
+- **Decision**: approve.
+
+## Spec Scope Fields *(mandatory)*
+
+- **Scope**: workspace/platform documentation and governance artifact.
+- **Primary Routes**: N/A. No reachable route, page, panel, action, modal, drawer, wizard, table, or form changes in this spec.
+- **Data Ownership**: No application data ownership changes. Spec-local artifacts are provisional documentation truth for future UI review only, subordinate to the canonical standards listed above until a later docs/product publication decision is approved.
+- **RBAC**: No runtime authorization changes. The contract must still require future specs to preserve workspace/tenant isolation, capability checks, and deny-as-not-found semantics where UI changes expose scoped data.
+
+## UI Surface Impact *(mandatory - UI-COV-001)*
+
+Does this spec add, remove, rename, or materially change any reachable UI surface?
+
+- [x] No UI surface impact
+- [ ] Existing page changed
+- [ ] New page/route added
+- [ ] Navigation changed
+- [ ] Filament panel/provider surface changed
+- [ ] New modal/drawer/wizard/action added
+- [ ] New table/form/state added
+- [ ] Customer-facing surface changed
+- [ ] Dangerous action changed
+- [ ] Status/evidence/review presentation changed
+- [ ] Workspace/environment context presentation changed
+
+## UI/Productization Coverage *(mandatory when UI Surface Impact is not "No UI surface impact"; otherwise write `N/A - no reachable UI surface impact` plus rationale)*
+
+N/A - no reachable UI surface impact.
+
+- **No-impact rationale**: This spec creates documentation and review artifacts only under `specs/370-global-surface-information-architecture-contract/`. It does not edit runtime files, routes, navigation, Filament providers, resources, pages, views, CSS, JavaScript, tests, or screenshot coverage artifacts.
+
+## Cross-Cutting / Shared Pattern Reuse
+
+- **Cross-cutting feature?**: yes, documentation-only.
+- **Interaction class(es)**: status messaging, header information hierarchy, dashboard signals, evidence/report viewers, diagnostics disclosure, zero-state metrics, operator next-action copy.
+- **Systems touched**: Spec-local artifacts only. Existing systems such as `BadgeCatalog`, `BadgeRenderer`, `OperationUxPresenter`, `OperationRunLinks`, `ActionSurfaceDeclaration`, and UI audit registries are referenced as context for future specs but not changed.
+- **Existing pattern(s) to extend**: Spec 368 recommendations, Spec 336 baseline compare decision-first pattern, Spec 344 customer review disclosure pattern, Spec 369 page-local decision summary pattern, and UI-COV-001 artifact discipline.
+- **Shared contract / presenter / builder / renderer to reuse**: N/A for this docs-only prep. Future runtime specs must reuse existing shared paths before inventing local UI semantics.
+- **Why the existing shared path is sufficient or insufficient**: Existing code paths already cover many page-local semantics. The missing piece is a reviewable documentation contract that says where decision, evidence, diagnostics, and metadata belong by surface type.
+- **Allowed deviation and why**: No runtime deviation. The contract may document Spec 370 IA review classes as review language only; these classes are not runtime `ActionSurfaceType` values and must not override canonical UI standards.
+- **Consistency impact**: Future specs should use one hierarchy for status/reason/impact/next-action and one rule set for technical metadata demotion.
+- **Review focus**: Confirm the contract remains a guardrail and does not become a mandated runtime framework.
+
+## OperationRun UX Impact
+
+N/A - no OperationRun start or link semantics touched.
+
+This spec does not create, queue, deduplicate, resume, block, complete, or deep-link to an `OperationRun`. It only states that future OperationRun-facing surfaces must separate execution outcome, data completeness, governance result, lifecycle/readiness, evidence, diagnostics, and technical metadata.
+
+## Provider Boundary / Platform Core Check
+
+- **Shared provider/platform boundary touched?**: documentation only.
+- **Boundary classification**: platform-core review language with provider-owned examples.
+- **Seams affected**: Future vocabulary guidance for provider connections, diagnostics, evidence, and technical details.
+- **Neutral platform terms preserved or introduced**: workspace, managed environment, provider connection, governed subject, operation, evidence, diagnostics, customer-safe, support/raw.
+- **Provider-specific semantics retained and why**: Microsoft/Intune examples may remain in source evidence because TenantPilot's current implementation is Microsoft-first, but the contract must not make Microsoft terms the default platform-core vocabulary.
+- **Why this does not deepen provider coupling accidentally**: The contract explicitly treats provider payloads, provider IDs, portal terms, raw API fields, and permission internals as technical/support detail unless the surface is intentionally diagnostic.
+- **Follow-up path**: Future provider-specific exceptions must be `document-in-feature` or `follow-up-spec`.
+
+## UI / Surface Guardrail Impact
+
+| Surface / Change | Operator-facing surface change? | Native vs Custom | Shared-Family Relevance | State Layers Touched | Exception Needed? | Low-Impact / `N/A` Note |
+|---|---|---|---|---|---|---|
+| Spec-local IA contract artifacts | no | N/A | status messaging, evidence/report viewers, diagnostics disclosure as documentation | none | no | Docs-only preparation package |
+| Future UI specs consuming the contract | future only | native/shared first | all relevant shared families | future surface-specific | future exceptions only | Out of scope for this spec |
+
+## Decision-First Surface Role
+
+N/A - no operator-facing surface is changed.
+
+The contract defines future review vocabulary for Primary Decision, Secondary Context, and Tertiary Evidence/Diagnostics surfaces, but does not reclassify or edit any live page.
+
+## Audience-Aware Disclosure
+
+N/A - no live detail or status surface is changed.
+
+The contract artifact must define disclosure expectations for operator, customer, auditor, platform admin, support, developer, mixed, and unknown audiences.
+
+## UI/UX Surface Classification
+
+N/A - no reachable operator-facing list, detail, queue, audit, config, or report surface is changed.
+
+The contract artifact must include the surface type matrix for future classification work.
+
+## Operator Surface Contract
+
+N/A - no new or materially refactored operator-facing page is introduced.
+
+The contract artifact itself defines the minimum fields future operator-surface contracts must answer.
+
+## Proportionality Review
+
+- **New source of truth?**: yes, but only provisional spec-local documentation truth for future UI review expectations. Canonical standards remain authoritative unless a later approved docs/product publication reconciles this package into them.
+- **New persisted entity/table/artifact?**: yes, Markdown artifacts under the spec package; no database or runtime persistence.
+- **New abstraction?**: no runtime abstraction, interface, service, resolver, presenter, or registry.
+- **New enum/state/reason family?**: no runtime enum/state/reason family.
+- **New cross-domain UI framework/taxonomy?**: a documentation taxonomy for surface/audience/scope review language, not a runtime framework and not the runtime `ActionSurfaceType` taxonomy.
+- **Current operator problem**: Operators and customer/auditor users lose time and trust when page-local UI shows technical metadata, zero metrics, and repeated statuses before the current decision and evidence basis.
+- **Existing structure is insufficient because**: Spec 368 and Spec 369 prove page-level work can improve one surface, but the same rule decisions recur across backup, operations, baseline, provider, diagnostics, evidence, and customer review. Existing specs do not provide one shared review artifact for later productization slices.
+- **Narrowest correct implementation**: Keep the contract as Markdown under this spec, anchored to audit evidence and examples. Do not add code, CI guards, shared components, target mockups, or docs/product publication unless separately reviewed.
+- **Ownership cost**: Future specs may reference the contract as a review artifact, but must still follow canonical standards and runtime Action Surface rules. Reviewers must prevent it from becoming a mandatory presenter/component framework or competing standards layer.
+- **Alternative intentionally rejected**: Direct runtime refactors across all affected pages, a new UI component library, static guard implementation, or global presenter layer. All are broader than the current need.
+- **Release truth**: current-release productization guardrail.
+
+### Compatibility posture
+
+This is a docs-only preparation package. Backward compatibility, migration shims, legacy aliases, data backfills, and fixture migrations are not applicable.
+
+## Testing / Lane / Runtime Impact
+
+- **Test purpose / classification**: N/A for application tests. Artifact review and `git diff --check` are sufficient for this preparation package.
+- **Validation lane(s)**: docs-only/manual review, no Pest lane required.
+- **Why this classification and these lanes are sufficient**: No runtime behavior, database schema, queue, route, Filament resource, Livewire component, policy, or asset changes are planned.
+- **New or expanded test families**: none.
+- **Fixture / helper cost impact**: none.
+- **Heavy-family visibility / justification**: none.
+- **Special surface test profile**: N/A.
+- **Standard-native relief or required special coverage**: N/A. The contract may require future specs to use browser/manual smoke only when they change reachable UI.
+- **Reviewer handoff**: Reviewers should confirm the package is docs-only, the contract remains narrow, the artifact examples are traceable to Spec 368, and follow-up specs are not hidden in the primary scope.
+- **Budget / baseline / trend impact**: none.
+- **Escalation needed**: document-in-feature if a future spec needs to deviate from the contract; follow-up-spec if repeated drift justifies automation.
+- **Active feature PR close-out entry**: N/A - preparation package only.
+- **Planned validation commands**:
+  - `./.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks`
+  - `git diff --check`
+  - Manual review of `spec.md`, `plan.md`, `tasks.md`, and `artifacts/*.md`.
+- **Runtime impact**: none. No env vars, migrations, queues, scheduler, storage, Graph calls, or Filament assets.
+
+## User Scenarios & Testing
+
+### User Story 1 - Review future UI specs against one IA contract (Priority: P1)
+
+As a product/engineering reviewer, I want future UI productization specs to use one repo-anchored surface information architecture contract, so I can detect bloat, duplicated status, and misplaced metadata before implementation.
+
+**Independent Test**: Review a future UI spec and confirm it declares surface type, audience, first-viewport decision content, evidence placement, diagnostics placement, metadata placement, and any contract deviation.
+
+**Acceptance Scenarios**:
+
+1. **Given** a future spec changes an operator detail page, **When** reviewers inspect its plan, **Then** the spec can be checked against the contract's header/main/sidebar/technical-details hierarchy.
+2. **Given** a future spec needs to show technical metadata early, **When** it is reviewed, **Then** it must document the surface type and why that exception is justified.
+3. **Given** a future UI spec repeats status/impact/next-action in multiple first-viewport cards, **When** it is reviewed, **Then** the contract gives reviewers a concrete basis to request consolidation.
+
+### User Story 2 - Preserve customer/auditor safety by default (Priority: P1)
+
+As a customer-facing reviewer or auditor, I want customer/auditor surfaces to default to outcome, evidence, limitation, and next action instead of internal diagnostics, so handoff artifacts are trustworthy and readable.
+
+**Independent Test**: Use the page assessment checklist to classify a customer/auditor surface and confirm raw IDs, provider payloads, internal reason ownership, debug labels, and operation internals are not default-visible unless explicitly justified.
+
+**Acceptance Scenarios**:
+
+1. **Given** a customer review or report surface is changed later, **When** the checklist is applied, **Then** customer-safe decision content is first and raw/support detail is collapsed or capability-gated.
+2. **Given** evidence is available, **When** the surface is assessed, **Then** evidence readiness, captured-at timing, limitations, and export/handoff action are separated from diagnostics.
+3. **Given** evidence is unavailable or blocked, **When** the surface is assessed, **Then** the limitation is stated without pretending the evidence is verified.
+
+### User Story 3 - Keep diagnostics useful without overwhelming decision surfaces (Priority: P2)
+
+As an operator or support user, I want diagnostic surfaces to lead with failure, likely cause, next check, and related evidence/operation, while regular decision surfaces keep raw diagnostics on demand.
+
+**Independent Test**: Apply the surface type matrix to a diagnostic page and a decision page and confirm the diagnostic page is allowed to show technical depth while the decision page demotes raw detail.
+
+**Acceptance Scenarios**:
+
+1. **Given** a diagnostic surface is changed later, **When** reviewers apply the contract, **Then** the first viewport must explain what failed, why it likely failed, what to check next, and where supporting evidence or operations live.
+2. **Given** a non-diagnostic detail page contains raw IDs or payload lineage, **When** it is assessed, **Then** that detail belongs in sidebar or collapsed technical details.
+3. **Given** a page has no current issues, **When** it renders, **Then** zero/error/no-attention metrics should not crowd out the current good state unless they are meaningful proof.
+
+## Functional Requirements
+
+- **FR-001**: The spec package MUST define a Global Surface Information Architecture Contract that is explicitly docs-only for this slice.
+- **FR-002**: The contract MUST define the first-viewport decision hierarchy as status, reason, impact, primary next action, affected objects, evidence availability, then diagnostics/technical metadata on demand.
+- **FR-003**: The contract MUST define header, main content, sidebar/aside, technical details, and evidence-area placement rules.
+- **FR-004**: The contract MUST define zero-metric suppression rules for healthy/no-action states.
+- **FR-005**: The contract MUST define at least these surface types: `decision_surface`, `operator_surface`, `workflow_surface`, `customer_surface`, `auditor_surface`, `evidence_surface`, `diagnostic_surface`, `configuration_surface`, `system_surface`, `portfolio_surface`, `support_surface`, and `unknown`.
+- **FR-006**: The contract MUST define at least these audiences: `operator`, `customer`, `auditor`, `platform_admin`, `support`, `developer`, `mixed`, and `unknown`.
+- **FR-007**: The contract MUST define at least these scope types: `workspace_scoped`, `environment_scoped`, `tenant_scoped`, `customer_scoped`, `system_scoped`, `mixed`, and `unknown`.
+- **FR-008**: The contract MUST define verification classes: `repo-verified`, `browser-verified`, `derived from existing implementation`, `foundation-real`, `plausible`, `not verified`, `not available`, and `deferred`.
+- **FR-009**: The package MUST include a page assessment checklist that future UI specs can use before implementation.
+- **FR-010**: The package MUST include a UI bloat pattern registry based on Spec 368 findings.
+- **FR-011**: The package MUST include copy and terminology rules that preserve provider-neutral platform language and customer-safe disclosure.
+- **FR-012**: The package MUST include a follow-up spec map that keeps page-specific refactors, diagnostic fixture fixes, and automation guardrails out of this scope.
+- **FR-013**: The package MUST include a source audit summary that identifies which Spec 368 inputs are available, missing, browser-verified, or not available.
+- **FR-014**: The package MUST include a validation report covering branch, HEAD, dirty/untracked files, source artifact availability, and preparation analysis result.
+- **FR-015**: The spec MUST NOT modify runtime application code, tests, migrations, routes, resources, views, policies, jobs, services, config, or assets.
+- **FR-016**: The contract MUST avoid creating a mandatory runtime presenter, badge system, UI framework, component library, or static guard in this slice.
+
+## Non-Functional Requirements
+
+- **NFR-001**: The contract must be concise enough to be applied during spec review without requiring a separate design governance process.
+- **NFR-002**: Every rule must be traceable to Spec 368 evidence, existing repo patterns, or an explicit `plausible`/`deferred` label.
+- **NFR-003**: The contract must preserve Filament v5 / Livewire v4 compatibility by referring future runtime work back to native Filament/shared primitives instead of custom UI systems.
+- **NFR-004**: The contract must preserve RBAC and tenant/workspace isolation expectations for future UI specs without changing authorization in this slice.
+- **NFR-005**: The contract must distinguish evidence from diagnostics and must not treat OperationRun internals as customer-safe proof by default.
+- **NFR-006**: The contract must keep provider-specific implementation detail out of platform-core default language unless the surface is explicitly provider-owned or diagnostic.
+
+## Out Of Scope
+
+- Runtime UI changes to any page.
+- Refactoring Baseline Profile, Backup Set, OperationRun, Restore Run, Operations Hub, Customer Review Workspace, Provider Connections, Diagnostics, Evidence Snapshot, Required Permissions, or System panel pages.
+- Browser screenshot updates for individual pages.
+- Target mockups or one target example per archetype.
+- System/auth fixture repair.
+- New Filament components, Blade views, CSS, JavaScript, assets, or design tokens.
+- New application tests, browser tests, static guards, CI checks, or lint rules.
+- New database tables, migrations, models, services, jobs, policies, routes, config, or OperationRun types.
+- Updating completed specs or removing close-out history.
+- Publishing the contract to `docs/product/` unless a later implementation review explicitly approves that repo-wide documentation location.
+- Replacing or renaming existing canonical UI standards, Action Surface classifications, or runtime `ActionSurfaceType` values.
+
+## Acceptance Criteria
+
+- **AC-001**: `spec.md`, `plan.md`, `tasks.md`, and `checklists/requirements.md` exist for Spec 370.
+- **AC-002**: The artifact set includes `source-audit-summary.md`, `surface-contract.md`, `surface-type-matrix.md`, `ui-bloat-patterns.md`, `page-assessment-checklist.md`, `copy-and-terminology-rules.md`, `follow-up-spec-map.md`, and `validation-report.md`.
+- **AC-003**: The contract explicitly states "Decision first. Diagnostics second. Evidence third. Technical metadata only on demand" and clarifies that evidence availability may appear in the decision layer while full evidence/proof remains distinct from diagnostics.
+- **AC-004**: The contract defines the required surface, audience, scope, verification, and layout/disclosure rules.
+- **AC-005**: The follow-up map excludes page-level runtime refactors and automation guardrails from this spec.
+- **AC-006**: Preparation analysis finds no blocking inconsistency across `spec.md`, `plan.md`, and `tasks.md`, or any finding is fixed only in Spec Kit artifacts.
+- **AC-007**: `git diff --check` passes for the prepared artifacts.
+- **AC-008**: No application/runtime files are modified.
+- **AC-009**: The package explicitly distinguishes Spec 370 IA review classes from existing product standards and runtime `ActionSurfaceType` values, and explicitly defers target mock/example artifacts.
+
+## Success Criteria
+
+- A future UI productization spec can cite this package and classify a changed page without inventing a new first-viewport hierarchy.
+- Reviewers can identify whether a surface is decision, workflow, evidence, diagnostic, customer/auditor, configuration, system, portfolio, support, or unknown.
+- Follow-up UI specs remain smaller because they can reuse this contract instead of redefining zero metrics, metadata demotion, evidence placement, and diagnostics disclosure.
+- The contract reduces overproduction risk by explicitly deferring code, guards, and broad page refactors.
+
+## Risks
+
+- The contract could be interpreted as a runtime framework instead of a documentation guardrail.
+- The surface taxonomy could grow beyond current evidence if future contributors add speculative categories.
+- Publishing a separate docs/product copy too early could create two sources of truth.
+- Future page specs may over-apply the contract to tiny UI changes where no material surface impact exists.
+
+## Assumptions
+
+- Spec 368 audit artifacts are the authoritative source evidence for this package.
+- Spec 369's page-local Baseline Profile work is completed/validated and should not be reopened by this prep.
+- The repo's current Spec Kit scripts provide branch/spec and plan setup; tasks and analysis are artifact-driven rather than shell-command-driven.
+- A docs-only spec package is sufficient for the first version of this contract.
+
+## Open Questions
+
+- None blocking preparation.
+- Non-blocking follow-up: whether a later implementation step should publish a stable copy under `docs/product/` or keep the contract spec-local until a second consuming UI productization spec validates it.
+
+## Follow-up Spec Candidates
+
+- Backup Set View decision-first productization.
+- OperationRun View metadata/proof separation polish.
+- Customer/Auditor Surface Safety Pass.
+- Diagnostic Surface Separation and browser fixture reachability for Required Permissions/System/Evidence Snapshot.
+- UI Bloat Regression Guard v1, only after this contract is validated by at least one additional runtime UI spec.
+- Docs/product publication or standards integration for the contract if repeated references prove the spec-local artifact is too hidden.
--- a/specs/370-global-surface-information-architecture-contract/tasks.md
+++ b/specs/370-global-surface-information-architecture-contract/tasks.md
@ -0,0 +1,65 @@
+# Tasks: Spec 370 - Global Surface Information Architecture Contract v1
+
+**Input**: Design documents from `specs/370-global-surface-information-architecture-contract/`
+**Prerequisites**: `spec.md`, `plan.md`, Spec 368 audit artifacts, `checklists/requirements.md`
+
+**Tests**: Docs-only package. No Pest/browser lane is required unless a later implementation step changes runtime UI.
+
+## Phase 1: Preparation Guardrails
+
+- [x] T001 Re-read `specs/370-global-surface-information-architecture-contract/spec.md`, `plan.md`, `tasks.md`, and `.specify/memory/constitution.md`.
+- [x] T002 [P] Confirm the package remains docs-only by checking no runtime paths outside `specs/370-global-surface-information-architecture-contract/` are modified.
+- [x] T003 [P] Inspect Spec 368 source inputs in `specs/368-platform-ui-signal-to-noise-browser-audit/audit.md`, `findings.md`, `recommendations.md`, `page-scorecard.csv`, `spec-candidates.md`, and `artifacts/raw/browser-notes.md`.
+- [x] T004 [P] Inspect the Spec 368 screenshot inventory under `specs/368-platform-ui-signal-to-noise-browser-audit/artifacts/screenshots/` and keep examples evidence-labeled.
+- [x] T005 Confirm Spec 369 is completed/validated context only and do not edit `specs/369-baseline-profile-decision-view/`.
+
+## Phase 2: Source Evidence Artifacts
+
+- [x] T006 [P] Review and finalize `specs/370-global-surface-information-architecture-contract/artifacts/source-audit-summary.md` so each referenced Spec 368 input uses exact verification class labels such as `repo-verified`, `browser-verified`, `derived from existing implementation`, `not available`, or `deferred`.
+- [x] T007 [P] Review and finalize `specs/370-global-surface-information-architecture-contract/artifacts/validation-report.md` with branch, HEAD, dirty/untracked files, source artifact availability, and preparation analysis result.
+- [x] T008 Ensure missing or blocked source evidence is recorded as `not available` or `deferred`, never invented.
+
+## Phase 3: Global Surface Contract
+
+- [x] T009 [US1] Review and finalize `specs/370-global-surface-information-architecture-contract/artifacts/surface-contract.md` with the first-viewport hierarchy: status, reason, impact, primary next action, affected objects, evidence availability, diagnostics second, technical metadata on demand.
+- [x] T010 [US1] Ensure the contract separates Header, Main Content, Sidebar/Aside, Technical Details, and Evidence Area responsibilities.
+- [x] T011 [US1] Ensure the contract defines zero-metric suppression and duplicate-truth controls without requiring a runtime component or static guard.
+- [x] T012 [US1] Ensure the contract defines verification classes and requires future facts to use them.
+
+## Phase 4: Surface, Audience, And Scope Matrix
+
+- [x] T013 [US1] Review and finalize `specs/370-global-surface-information-architecture-contract/artifacts/surface-type-matrix.md` with all required Spec 370 IA review classes from the spec, explicitly stating they are not runtime `ActionSurfaceType` values or replacements for canonical UI standards.
+- [x] T014 [US2] Confirm each audience type in the matrix states decision need, forbidden default burden, allowed technical depth, evidence expectation, diagnostics expectation, and action model.
+- [x] T015 [US1] Confirm each scope type states default scope treatment and raw ID placement rules.
+- [x] T016 [US3] Confirm diagnostic and system surfaces are allowed more technical depth while still requiring impact and next action.
+
+## Phase 5: Bloat, Copy, And Checklist Artifacts
+
+- [x] T017 [US1] Review and finalize `specs/370-global-surface-information-architecture-contract/artifacts/ui-bloat-patterns.md` with Spec 368-derived patterns and prevention rules.
+- [x] T018 [US2] Review and finalize `specs/370-global-surface-information-architecture-contract/artifacts/copy-and-terminology-rules.md` with provider-neutral, customer-safe, and operator-action-oriented language rules.
+- [x] T019 [US1] Review and finalize `specs/370-global-surface-information-architecture-contract/artifacts/page-assessment-checklist.md` so future specs can assess pages before implementation.
+- [x] T020 [US1] Ensure the page assessment checklist ends with one review outcome and one workflow outcome.
+
+## Phase 6: Follow-up Boundary
+
+- [x] T021 Review and finalize `specs/370-global-surface-information-architecture-contract/artifacts/follow-up-spec-map.md`.
+- [x] T022 Confirm page-level runtime refactors, browser fixture repair, screenshot refreshes, target mock/examples per archetype, static guards, and docs/product publication remain follow-up candidates and are not hidden inside Spec 370.
+- [x] T023 Confirm future automation guard work requires a separate spec after at least one additional consuming UI productization spec validates the contract.
+
+## Phase 7: Review, Analysis, And Validation
+
+- [x] T024 Run `./.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks`.
+- [x] T025 Run a read-only preparation analysis across `spec.md`, `plan.md`, and `tasks.md` using the repo's `speckit-analyze` guidance.
+- [x] T026 Fix only Spec Kit preparation artifacts if the preparation analysis finds bounded inconsistencies.
+- [x] T027 Run `git diff --check`.
+- [x] T028 Record final readiness, no-runtime-impact, branch name, and any remaining non-blocking question in `artifacts/validation-report.md` only after T024-T027 complete.
+- [x] T029 Confirm no application/runtime implementation was performed.
+
+## Test Governance Checklist
+
+- [x] Lane assignment is named and is the narrowest sufficient proof for the changed behavior. Docs-only/manual review is sufficient because no runtime behavior changes.
+- [x] New or changed tests stay in the smallest honest family, and any heavy-governance or browser addition is explicit. No tests are added.
+- [x] Shared helpers, factories, seeds, fixtures, and context defaults stay cheap by default; any widening is isolated or documented. No helpers or fixtures are added.
+- [x] Planned validation commands cover the change without pulling in unrelated lane cost. `check-prerequisites`, read-only analysis, and `git diff --check` cover the prep package.
+- [x] The declared surface test profile or `standard-native-filament` relief is explicit. N/A - no reachable UI surface changes.
+- [x] Any material budget, baseline, trend, or escalation note is recorded in the active spec or PR. None.