Visual Coverage Map — Module 08
Canonical profile audited: .agents/visual-profiles/trainings/construction-plan-drafting-and-coordination.md from PR #4527, profile version 1, reviewed 2026-10-05. The profile is read-only for this PR.
| Asset | Objective | Learning question | Medium choice / profile fit | Technical plausibility and authority | Semantic colors / construction-document language | Accessibility | Status |
|---|---|---|---|---|---|---|---|
| design-exchange-loop | 1–5 | What is the correct iterative ARCH–STRUCT workflow, including changes to structural design inputs? | Shared Flowchart. Correct for the proposal → geometry/load-input screen → structural review → markup/response → coordinated basis → detailed design/recheck loop. | Explicitly re-establishes use/load/equipment/weight/opening/core/expansion inputs so “no visible framing change” cannot bypass structural review. | ARCH/STRUCT roles and states are text-labeled; review/markup/controlled-basis terminology matches construction-document coordination. | Node labels and decision branches carry all meaning independently of color. | Profile-aligned |
| Architecture to Structure — Required Information Map | 1 | What controlled architectural information does structure need? | TrainingConceptDiagram — grid. Correct non-process map of parallel information classes. | Geometry, levels, functional/façade/equipment constraints, site/below-grade interfaces, and future assumptions are plausible coordination inputs, not structural design output. | Neutral grid; “Architecture to Structure” direction is textual, not color-coded. | Informative title/description; all input categories are explicit. | Profile-aligned |
| Structure to Architecture — Required Response Map | 2,4 | What structural information must come back to architecture? | TrainingConceptDiagram — grid. Correct non-process map of parallel response classes. | Grid/support, depth/transfer, opening/stair/roof, foundation/movement/equipment/expansion consequences are plausible structural coordination outputs. | Neutral grid; structural response categories are text-labeled and do not rely on a discipline color. | Title/description plus explicit category text. | Profile-aligned |
| column-space-conflict | 3 | How should a column–door/room conflict be resolved? | Shared Flowchart. Appropriate because alternatives require architectural and structural checks and possible iteration. | Does not authorize moving/deleting a support independently; requires load-path/foundation and function/access review. | Uses clash/options/check/update language and avoids fake dimensions or unreviewed openings. | Explicit decision branches and terminal state. | Profile-aligned |
| headroom-transfer-conflict | 3,4 | How should beam depth/transfer/headroom conflicts be resolved? | Shared Flowchart. Appropriate for 3D-overlay check → alternatives → multidisciplinary review → update loop. | Preserves member depth, level, ceiling/service, opening, and headroom constraints without presenting an unsafe one-step “fix.” | Construction-document terms identify levels/depth zones/services; no color-only clash meaning. | Full text labels; success/revise states named. | Profile-aligned |
| foundation-service-interface | 3,4 | How should foundation and buried-service conflicts be resolved? | Shared Flowchart. Appropriate for below-grade overlay, structural/geotechnical check, service check, and coordinated issue. | Explicitly rejects routing through or shifting structural elements without responsible engineering review. | Uses plan/section/level/no-cut/support terminology consistent with site/structural coordination. | Text labels and branches communicate the interface without relying on color. | Profile-aligned |
Profile-level audit
- Primary visual modes: two deterministic information grids plus four true coordination workflows, matching the canonical profile's grid + shared-flowchart grammar.
- Technical plausibility: clash workflows prohibit unilateral openings/support shifts; the exchange workflow now screens architectural revisions for changed structural design inputs, not only moved geometry.
- Semantic discipline colors: ARCH/STRUCT direction and issue state are explicit in labels and positions. No visual assumes a color is sufficient to communicate discipline or approval.
- Construction-document visual language: uses grids, levels, sections, depth zones, openings, markups, issue states, coordinated basis, and plan/section/level outputs rather than cinematic or decorative graphics.
- Accessibility: every asset has title/description or shared-renderer equivalent; branches and discipline roles are text-labeled.
- Cognitive load: each clash visual isolates one coordination family. The information maps remain separate from the detailed conflict workflows.
- Rendered-geometry limitation: source-level/profile alignment was audited; no browser rendering or production geometry inspection was performed.