Visual Coverage Map — Module 07
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 |
|---|---|---|---|---|---|---|---|
| requirement-to-space-program | 1,3 | How does a client statement become a measurable multidisciplinary design basis? | Shared Flowchart. Correct for the traceable brief → requirements → program → layout/interface-review loop. | Does not prescribe architectural form; professional control remains with the responsible architect while engineering interfaces are screened. | Uses brief/program/interface/design-basis vocabulary rather than faux plans. | Shared title/description and labeled decision branches; no color dependence. | Profile-aligned |
| Programming Relationship Matrix | 2 | How do I classify must-adjoin, near, separate, and zone-transition relationships before drawing a plan? | TrainingConceptDiagram — grid. Deliberately replaces a process flow with a relational matrix, matching the profile's grid/comparison mode. | Relationship classes are programming instructions, not universal adjacency rules; public/controlled-private/service transitions are explicitly project-specific. | Neutral cards avoid a misleading “three-color zoning plan.” Relationship type and zone names are textual, so semantics do not depend on color. | Informative title/description/details; all four relationship classes are explicit text. | Profile-aligned |
| Functional Zoning and Circulation Relationship Map | 2 | How do public, controlled/private, service, vertical-circulation, wet/service-core, and principal-path systems relate? | TrainingConceptDiagram — grid. Non-process, deterministic relationship map; intentionally not a fake architectural floor plan. | Shows programming relationships and interface checks without prescribing room geometry or a universal arrangement. | Public/private/service/vertical/wet-core/path identities are text-labeled. Neutral construction-document style keeps architecture subordinate to the programming question. | Title/description/details explain how to read the map; every zone/path is named and no color-only meaning is used. | Profile-aligned |
| preliminary-design-package | 3,4,5 | What must a preliminary issue communicate to consultants? | Shared Flowchart. Correct because several controlled information streams converge into a package-completeness decision. | Includes plans/sections/levels, program, assumptions, interfaces, constraints, and questions without implying final discipline design. | Controlled issue/package/question terminology matches drawing/document coordination practice. | Stream labels and decision branches are explicit. | Profile-aligned |
| consultant-issue-sequence | 5 | How do consultant markups become controlled design decisions? | Shared Flowchart. Correct for response, clarification, incorporation, reissue, and release loop. | Preserves professional decision ownership and does not imply that coordination comments transfer design responsibility. | Uses markup/response/decision/reissue/controlled basis language; no decorative office/CAD imagery. | Labeled loop and branches provide full nonvisual meaning. | Profile-aligned |
Profile-level audit
- Primary visual modes: two deterministic relational grids plus three true workflows. This corrects the prior all-flowchart imbalance and better matches architectural programming's spatial/relational learning target.
- Technical plausibility: relationship diagrams teach categories and interfaces, not a universal floor plan. They do not invent dimensions, area ratios, accessibility geometry, or code values.
- Semantic discipline/zone colors: public, controlled/private, service, wet/service-core, vertical circulation, and principal paths are encoded by text/position rather than color. No three-color zoning convention is presented as universal.
- Construction-document visual language: controlled brief, program, issue, assumptions, consultant markups, and coordination-basis terminology is used; no fake architectural sheet or floor plan is presented.
- Accessibility: all five assets have informative titles/descriptions; the two non-process diagrams include textual reading guidance, and shared workflows have labeled branches.
- Cognitive load: each diagram addresses one programming relationship question; the relationship maps remain schematic and do not overload room geometry.
- Rendered-geometry limitation: source-level/profile alignment was audited; no browser rendering or production geometry inspection was performed.