Cross-Committee Coordination Framework
Faculty Working Draft
Prepared September 2026
Purpose
The six IMD committees have distinct charges, but their decisions are interdependent. A recommendation about specialization can change coding expectations, foundational coursework, equipment demand, portfolio requirements, career messaging, faculty workload, and the sequence through which students move across the curriculum.
This document identifies the principal areas of intersection between the Specializations Committee and the other five committees. It proposes an order of work, clear communication points, and shared documentation practices intended to prevent one committee from making decisions that constrain or disrupt another committee's work without prior notice.
The guiding principle is:
Independent investigation, coordinated recommendations, and no surprise decisions.
1. Committee Charges
| Committee | Primary Charge |
|---|---|
| Coding | Shared coding language; B.A. coding needs; creation of an AI and IMDM-B.S. AI specialization |
| Portfolio | Portfolio development across the curriculum; role of IMDM351 |
| Labs | Integration of laboratories, facilities, and equipment into required coursework |
| IMDM101 | IMDM101 curriculum; review of required Art courses |
| Specializations | Support for specializations; Game Design pathway; project continuity across courses |
| Vision | Career pathways; Industry Advisory Board |
The committees should not be treated as isolated owners of unrelated topics. Each committee leads work within its charge, but leadership does not eliminate the need to consult committees whose work will be affected.
2. Three Levels of Cross-Committee Communication
Not every issue requires a joint committee. The level of coordination should match the impact of the decision.
| Level | When It Applies | Required Action |
|---|---|---|
| Inform | The work is internal to one committee but may be useful context for another. | Share a short update, working document, or meeting note. No approval is requested. |
| Consult | A proposal affects another committee's assumptions, workload, resources, or recommendations. | Share the proposal before it is finalized, ask specific questions, provide a response window, and record the response. |
| Joint Recommendation | The issue falls directly within two or more committee charges or cannot be implemented without shared ownership. | Designate representatives, divide responsibilities, co-author the recommendation, and document unresolved questions. |
Consultation Threshold
A committee should move from inform to consult whenever its proposal would:
- add, remove, rename, or substantially revise a required course;
- establish a prerequisite or assume a competency taught elsewhere;
- create a new specialization, concentration, or pathway;
- require specific laboratory access, equipment, software, staffing, or funding;
- add portfolio, documentation, or Capstone expectations;
- make public claims about careers, professional preparation, or student outcomes;
- affect another committee's timeline or deliverable; or
- commit the program to a public-facing curricular direction.
If two committees are explicitly charged with the same outcome, consultation is not sufficient. The outcome requires a joint recommendation.
3. Intersection Overview
| Committee | Primary Intersection with Specializations | What Specializations Needs | What the Other Committee Needs | Coordination Level |
|---|---|---|---|---|
| Coding | Technical foundations for all specializations; B.A. coding expectations; shared ownership of AI specialization | Coding competency map, language decisions, prerequisite feasibility, B.A./B.S. technical distinctions | Specialization outcomes, role profiles, project needs, and required technical depth | Consult for Game Design; Joint Recommendation for AI |
| Portfolio | Evidence of specialization, portfolio milestones, project documentation, and IMDM351 | Common documentation framework and placement of portfolio milestones | Examples of what mastery looks like in each specialization | Joint design of milestones; consult on course structure |
| Labs | Equipment, software, space, access, technical support, and production capacity | Feasibility, capacity, costs, scheduling, and required facility experiences | Forecast of specialization projects, enrollments, workflows, and resource demand | Consult before curricular commitments |
| IMDM101 | Early exposure to possible pathways; shared foundations; relationship to Art requirements | Confirmed introductory outcomes and realistic preparation | Specialization competencies that should be introduced, but not mastered, early | Consult during foundation design |
| Vision | Career claims, role definitions, advisory input, external relevance, and public messaging | Labor-market evidence, alumni and industry feedback, and transferability of skills | Clear specialization outcomes, portfolio evidence, and questions for external validation | Consult before public claims; joint work on messaging |
4. Specializations and Coding
Areas of Intersection
The Coding Committee's decisions establish technical assumptions that affect every specialization. A Game Design pathway may require real-time programming, object-oriented concepts, version control, or scripting. An AI pathway may require data handling, Python, APIs, machine-learning concepts, or advanced CS prerequisites. The Specializations Committee cannot define a viable pathway without knowing where and when students develop these abilities.
The overlap is especially direct for AI. The Coding Committee is explicitly charged with creating an AI and IMDM-B.S. AI specialization, while the Specializations Committee is charged with the broader structure and support of specializations. Neither committee should produce a complete AI pathway independently.
Division of Responsibility for AI
| Coding Committee Leads | Specializations Committee Leads | Joint Decisions |
|---|---|---|
| Technical competency map | Common specialization framework | Name and identity of the pathway |
| B.A. coding expectations | Relationship to project continuity | Shared learning outcomes |
| B.S. AI prerequisites and elective feasibility | Relationship to IMDM290, IMDM390, and Capstone | Course sequence and credit structure |
| Programming languages and technical foundations | Cross-track structure and student journey | B.A./B.S. distinctions and shared core |
| Technical course gaps | Integration with portfolio, production, and specialization evidence | New course recommendations |
Example: Shared Coding Language
If the Coding Committee recommends a single language or environment for the B.A., the Specializations Committee should review the proposal before it becomes a curricular assumption.
The review should ask:
- Does the choice support the forms of work envisioned in Game Design, AI, XR, physical computing, and other likely pathways?
- Does it provide a reasonable bridge into IMDM227, IMDM290, and later production courses?
- Does a specialization require a second language, engine, or environment, and if so, where is that transition introduced?
- Are students learning transferable programming concepts or only one tool?
The Coding Committee retains leadership over the coding recommendation, but it should receive specialization use cases before finalizing that recommendation.
Required Communication Points
- Before the Specializations Committee drafts required course sequences: Coding shares its current-state competency map and emerging language recommendations.
- Before Coding finalizes B.A. expectations: Specializations provides examples of the technical tasks expected in Game Design, AI, and other proposed pathways.
- Before either committee recommends an AI specialization: The committees co-author a single framework or explicitly reconcile their separate sections.
- Before proposing a new technical course or prerequisite: Both committees review student access, track differences, staffing, and time to degree.
5. Specializations and Portfolio
Areas of Intersection
A specialization becomes visible when students can demonstrate a coherent body of work and explain their developing area of expertise. The Specializations Committee should define the kinds of evidence that demonstrate depth. The Portfolio Committee should determine how students document, revise, organize, and present that evidence across the curriculum.
The committees should not independently design parallel portfolio requirements.
Division of Responsibility
| Specializations Committee Leads | Portfolio Committee Leads | Joint Decisions |
|---|---|---|
| Competencies and role-specific evidence | Program-wide documentation practices | Specialization portfolio milestones |
| Examples of mastery in each pathway | Placement and timing of portfolio development | Required handoff artifacts across courses |
| Relationship between projects and specialization identity | Role of IMDM351 | Common standards for credits, process, and reflection |
| Capstone or advanced demonstration criteria | Portfolio platforms, review structures, and presentation practices | How specialization is represented in the graduating portfolio |
Example: Game Design Portfolio Evidence
The Specializations Committee may determine that Game Design students should show small prototypes, playtesting and revision, one substantial collaborative project, a role-specific area of depth, and a Capstone or advanced demonstration.
The Portfolio Committee then determines:
- where students learn to document prototypes and iteration;
- when role attribution and case-study writing are introduced;
- whether IMDM351 supports these milestones;
- how unfinished, collaborative, and technically complex work should be represented; and
- when faculty review the developing body of work.
Example: AI Portfolio Evidence
The Specializations Committee may identify provenance, model and tool disclosure, dataset documentation, evaluation, failure analysis, and responsible-practice statements as essential evidence.
The Portfolio Committee determines how those elements become part of a common documentation and presentation framework rather than isolated requirements in one AI course.
Required Communication Points
- After specialization competencies are drafted: Specializations sends examples of required evidence to Portfolio.
- Before portfolio milestones or IMDM351 changes are finalized: Portfolio tests whether its structure can accommodate specialization-specific evidence.
- Before Capstone demonstration criteria are recommended: The committees align Capstone documentation with the broader portfolio sequence.
- After pilots: The committees review actual student examples together to determine whether the requirements are clear and sustainable.
6. Specializations and Labs
Areas of Intersection
Specializations create predictable resource demands. Game Design may require development workstations, controllers, playtesting space, game engines, audio tools, XR equipment, version control, and reliable build archiving. AI may require APIs, instructional service budgets, GPU access, local models, data storage, privacy controls, cameras, sensors, and technical support.
The Labs Committee cannot plan effectively without knowing what the proposed pathways require. The Specializations Committee should not promise students particular production experiences until capacity and access have been assessed.
Division of Responsibility
| Specializations Committee Leads | Labs Committee Leads | Joint Decisions |
|---|---|---|
| Definition of curricular experiences and project types | Capacity, access, maintenance, scheduling, and support | Required facility experiences |
| Forecast of tools and workflows | Equipment and software standards | Feasible enrollment and section capacity |
| Required level of student independence | Safety, training, and checkout procedures | Pilot resource plan and implementation timeline |
| Priority use cases | Cost and lifecycle planning | Alternatives when preferred resources are unavailable |
Example: Required AI Production Experience
If an AI specialization requires students to build an interactive system using local or cloud models, the Labs Committee needs to determine:
- whether students will use managed APIs, local models, shared computing, or a combination;
- what the instructional cost will be;
- how data and account access will be managed;
- whether the lab can support simultaneous course use;
- what technical support is required; and
- how projects will be archived when external services change.
The specialization should not advertise this experience until the resource pathway is credible.
Example: Game Production and Playtesting
If Game Design students are expected to complete sustained team productions, the Labs Committee should evaluate workstation capacity, shared storage, controller access, testing space, sound support, and evening or weekend availability. The Specializations Committee should provide expected team sizes, project types, software, and production milestones.
Required Communication Points
- During early pathway design: Specializations sends Labs a resource-use scenario, not merely a shopping list.
- Before a course becomes required: Labs provides a written feasibility and capacity response.
- Before public launch: Both committees confirm that required experiences can be offered equitably and repeatedly.
- After each pilot: Labs reports actual usage, failures, costs, bottlenecks, and support needs.
7. Specializations and IMDM101
Areas of Intersection
IMDM101 should introduce the program's common identity and give students enough exposure to recognize possible directions. It should not attempt to teach the full foundation of every specialization.
The Specializations Committee can identify which concepts or experiences students should encounter early. The IMDM101 Committee determines how those expectations fit within a coherent introductory course.
The review of required Art courses also affects specialization pathways, particularly the relationship among visual design, spatial practice, digital-media production, technical art, and the B.A./B.S. distinction.
Division of Responsibility
| Specializations Committee Leads | IMDM101 Committee Leads | Joint Decisions |
|---|---|---|
| Identification of early specialization signals | IMDM101 course design and scope | Which specialization concepts belong in the common introduction |
| Examples of future pathways | Introductory assignments and assessment | Shared language about the student's curricular journey |
| Long-term competency needs | Entry-level expectations and workload | Handoff materials from IMDM101 |
| Explanation of how Art foundations support pathways | Review of required Art courses | Consequences of changing Art requirements |
Example: Early Game Design Exposure
The Specializations Committee might request that students encounter rules, feedback, player action, and prototyping early in the program. The IMDM101 Committee could decide whether this appears as a short physical-game activity, an interactive object, a critical example, or part of another project.
The Specializations Committee should define the reason for the exposure, not prescribe the entire assignment.
Example: Early AI Exposure
The Specializations Committee might request that students distinguish rule-based behavior from machine-learning systems and begin discussing data, authorship, and automation. The IMDM101 Committee decides whether this belongs in a reading, discussion, comparison exercise, or small creative experiment.
IMDM101 should not be expected to teach model training or advanced technical practice merely because an AI specialization is being considered.
Required Communication Points
- After specialization competencies are drafted: Specializations identifies only the concepts that require early exposure.
- Before IMDM101 outcomes are finalized: The IMDM101 Committee evaluates scope, sequencing, and workload.
- Before Art requirements are changed: The IMDM101 Committee shares the proposed change and its rationale; Specializations provides an impact analysis for current and proposed pathways.
- After IMDM101 pilots: Both committees examine whether students are better able to recognize pathways without overloading the introductory course.
8. Specializations and Vision
Areas of Intersection
Specializations imply career and professional identities. A pathway called Game Design or AI will shape student expectations, recruitment, advising, public messaging, external partnerships, and faculty hiring.
The Specializations Committee should define curricular outcomes and the evidence students will produce. The Vision Committee should test career claims, identify relevant fields and roles, and gather external evidence through alumni, employers, practitioners, and the Industry Advisory Board.
External advice should inform curriculum, but faculty retain responsibility for curricular decisions.
Division of Responsibility
| Specializations Committee Leads | Vision Committee Leads | Joint Decisions |
|---|---|---|
| Curricular identity and learning outcomes | Career pathway research | Public-facing description of the specialization |
| Student roles and portfolio evidence | Alumni, employer, and practitioner input | Claims about professional preparation |
| Project and Capstone expectations | Industry Advisory Board structure and questions | External review of proposed pathways |
| Faculty and curricular gaps | Transferable-skill analysis | Priority partnerships and experiential opportunities |
Example: Game Design Career Messaging
The Specializations Committee may define preparation in systems design, prototyping, game programming, technical art, interaction, sound, and collaborative production.
The Vision Committee should test whether public messaging accurately represents opportunities in commercial games, independent development, serious games, simulation, interactive experience design, location-based entertainment, technical art, UX, research, and entrepreneurship. It should guard against implying a single AAA employment pipeline.
Example: AI Career Messaging
The Specializations Committee may distinguish creative AI, intelligent-media production, human-AI interaction, and technical AI depth.
The Vision Committee should ensure that the B.A. pathway does not automatically promise machine-learning engineering preparation and that B.S. claims match the actual mathematics, algorithms, software, and advanced AI coursework students complete.
Required Communication Points
- During pathway development: Vision provides current role and field research before course lists are fixed.
- After a draft pathway exists: Specializations gives Vision a concise statement of outcomes, student work, and intended roles.
- Before consulting an advisory board: The committees agree on specific questions and provide common background materials.
- Before public launch, recruitment, or hiring language: Both committees review and approve the factual basis of claims within their respective charges.
- After external consultation: Vision shares the evidence, not only a verbal summary, and Specializations records how the evidence affected the proposal.
9. Cross-Committee Decisions by Issue
| Issue | Lead | Required Partners | Decision Mode |
|---|---|---|---|
| General framework for IMD specializations | Specializations | All committees consulted | Specializations recommendation after impact review |
| Game Design pathway | Specializations | Coding, Portfolio, Labs, and Vision; IMDM101 consulted | Specializations lead with documented consultation |
| AI specialization | Coding and Specializations | Portfolio, Labs, Vision, and IMDM101 consulted | Joint recommendation |
| B.A. shared coding language | Coding | Specializations and IMDM101; Labs where software affects facilities | Coding lead with consultation |
| Project continuity across courses | Specializations | Portfolio; Coding, Labs, and IMDM101 as affected | Specializations and Portfolio joint design of handoffs |
| Portfolio milestones and IMDM351 | Portfolio | Specializations and Vision; course owners as affected | Portfolio lead with consultation |
| Required facility or equipment experience | Labs and relevant curricular committee | Specializations where pathway-related | Joint feasibility recommendation |
| Changes to IMDM101 | IMDM101 | Coding and Specializations; Portfolio where documentation begins | IMDM101 lead with consultation |
| Changes to required Art courses | IMDM101 committee under its charge | Specializations, Portfolio, and relevant Art faculty | Consultation before recommendation |
| Career claims for a specialization | Vision and Specializations | Advisory Board and relevant faculty consulted | Joint public-facing language |
| Industry Advisory Board questions | Vision | All committees invited to submit targeted questions | Vision lead; findings shared program-wide |
| Faculty-hiring rationale tied to a pathway | Relevant curricular committee and program leadership | Specializations, Vision, and affected committees | Joint evidence packet |
10. Optimal Order of Work
The committees can work concurrently, but their decision points should be sequenced.
Phase 1: Shared Definitions and Current-State Mapping
All committees begin together.
Agree on:
- the difference among a specialization, concentration, advising pathway, and elective cluster;
- the Introduced, Practiced, Advanced, and Demonstrated framework;
- the current degree and course structure;
- the distinction between published and enacted curriculum; and
- a common reporting template.
Each committee then maps the current state within its charge. No committee should begin by finalizing new courses.
Phase 2: Foundational Input Briefs
The Coding, Portfolio, Labs, IMDM101, and Vision committees prepare short input briefs that the Specializations Committee can use.
| Committee | Input Needed by Specializations |
|---|---|
| Coding | Current coding progression, B.A./B.S. differences, likely language direction, prerequisite barriers, and AI ownership questions |
| Portfolio | Current portfolio touchpoints, proposed milestones, documentation standards, and possible role of IMDM351 |
| Labs | Current resources, access, capacity, support limits, and known future commitments |
| IMDM101 | Proposed foundational outcomes, current course role, and possible changes to Art requirements |
| Vision | Current career map, priority external questions, and initial advisory-board timeline |
These briefs do not need to contain final recommendations. They should state current evidence, working assumptions, constraints, and open questions.
Phase 3: Draft Specialization Cases
Using those inputs, the Specializations Committee develops provisional cases for Game Design and other possible pathways. The Coding and Specializations committees jointly develop or reconcile the AI case.
Each draft should include:
- identity and purpose;
- competencies and outcomes;
- B.A./B.S. relationship;
- current assets and gaps;
- proposed course sequence;
- project-continuity pathway;
- portfolio evidence;
- facility and equipment needs;
- faculty and staffing needs;
- career claims; and
- decisions that depend on another committee.
Phase 4: Dependency and Impact Review
Before recommendations are finalized, every affected committee reviews the draft using the same questions:
- What assumptions does this proposal make about our work?
- What new responsibility, workload, cost, or constraint would it create?
- What part can be implemented now?
- What requires pilot evidence, formal curricular change, staffing, or funding?
- What conflict or dependency has not yet been resolved?
The originating committee responds in writing and revises the proposal or records the unresolved issue.
Phase 5: Pilot and Feasibility Work
Where possible, test recommendations through special topics, advising materials, syllabus language, shared portfolio prompts, limited equipment pilots, or targeted project pathways before formalizing them.
Pilots should collect evidence on student demand, learning, workload, access, cost, staffing, resource use, and project quality.
Phase 6: Coordinated Recommendations
Final committee reports should use a shared structure and explicitly identify:
- decisions within the committee's authority;
- decisions requiring another committee's action;
- joint recommendations;
- unresolved disagreements;
- immediate, medium-term, and long-term actions; and
- evidence still needed.
The final departmental synthesis should show how the six reports fit together rather than presenting them as unrelated packets.
11. Information-Sharing Structure
A. Designated Liaisons
Each committee should identify one liaison for cross-committee communication. The liaison does not make decisions for the committee. The liaison ensures that relevant drafts, questions, decisions, and responses move between groups.
B. Monthly Cross-Committee Checkpoint
A short monthly meeting of committee chairs or liaisons should use a fixed three-part update:
- What we learned
- What we are considering
- What we need from another committee
The purpose is early warning and dependency management, not full committee deliberation.
C. Shared Working Space
All committees should use one shared location with a predictable structure:
- Shared Definitions and Templates
- Current-State Maps
- Committee Input Briefs
- Draft Proposals
- Cross-Committee Reviews
- Decision Log
- Pilot Evidence
- Final Recommendations
Documents should have a visible owner, status, version date, response deadline where applicable, and change log.
D. Required Shared Documents
#### Committee Input Brief
- Current state
- Evidence reviewed
- Working assumptions
- Constraints
- Emerging recommendations
- Decisions that may affect other committees
- Questions for other committees
#### Cross-Committee Consultation Request
- Proposal or decision under consideration
- Why the receiving committee is affected
- Specific questions requiring response
- Consequences of the decision
- Supporting evidence
- Response deadline
- Contact person
#### Decision Log
| Date | Issue | Committee or Committees | Decision Status | Evidence | Dependencies | Next Step |
|---|---|---|---|---|---|---|
#### Dependency Register
| Proposal | Depends On | Affected Committee | Input Needed By | Status | Risk if Unresolved |
|---|---|---|---|---|---|
12. Practical Examples of the Process
Scenario 1: Coding Proposes a New B.A. Language
- Coding develops the rationale and preliminary competency map.
- Coding sends Specializations and IMDM101 a consultation request with specific use cases.
- Specializations tests the proposal against Game Design, AI, XR, and other pathway needs.
- IMDM101 reviews implications for introductory preparation.
- Labs reviews software, workstation, and support consequences if relevant.
- Coding revises the proposal and records how the responses were addressed.
- The recommendation proceeds with the consultation record attached.
Scenario 2: Specializations Proposes a Game Design Course
- Specializations defines the missing competency and shows why existing courses do not address it.
- Coding reviews programming assumptions and access across tracks.
- Portfolio reviews proposed documentation and specialization evidence.
- Labs reviews workstations, software, playtesting, and scheduling.
- Vision reviews role and career claims.
- IMDM101 reviews whether any introductory exposure is needed.
- Specializations revises the proposal before recommending a pilot or permanent course.
Scenario 3: Coding and Specializations Develop AI
- Coding maps technical requirements, prerequisites, and B.S. elective options.
- Specializations maps the common specialization structure, cross-track pathway, continuity, and demonstration requirements.
- The committees hold a joint working session and produce one shared outcome map.
- Portfolio reviews provenance, evaluation, and responsible-practice evidence.
- Labs reviews compute, storage, APIs, data, and support.
- Vision reviews differentiation from other UMD AI programs and career claims.
- IMDM101 reviews which introductory concepts belong in the common foundation.
- A joint draft returns to all affected committees before formal recommendation.
Scenario 4: Portfolio Proposes a New IMDM351 Role
- Portfolio defines the purpose, timing, and expected student artifacts.
- Specializations tests whether the course supports distinct Game Design, AI, and other specialization evidence.
- Vision reviews professional and career relevance.
- Labs reviews whether documentation depends on specialized capture or production resources.
- Portfolio revises the proposal and records which specialization needs it serves.
Scenario 5: Labs Proposes Required Equipment Experiences
- Labs identifies facilities that could be embedded in required courses.
- IMDM101 and Specializations evaluate which experiences belong at introductory, intermediate, advanced, or demonstrated levels.
- Coding reviews technical preparation where applicable.
- Portfolio determines how students document facility proficiency.
- The relevant curricular committee and Labs jointly recommend placement, training, and assessment.
Scenario 6: Vision Seeks Industry Advisory Board Feedback
- Vision asks each committee for one to three focused questions.
- Specializations provides pathway drafts, role definitions, and portfolio examples rather than asking whether an industry representative simply “likes” the idea.
- Vision conducts the consultation and preserves the evidence, including disagreement and uncertainty.
- Findings are shared with all committees.
- Each committee records whether and how the evidence affects its recommendation.
13. Transparency Rules
To mitigate closed-door decisions without making every discussion cumbersome, the committees should adopt the following rules:
- Working drafts are visible. Draft status should be clear, but affected committees should not first encounter a proposal after it has been treated as final.
- Cross-committee impacts are declared. Every recommendation identifies which committees, courses, resources, and timelines it affects.
- Consultation happens before commitment. A committee should not ask for input after public language, course structures, or resource promises have already been settled.
- Responses are recorded. Meeting summaries should capture recommendations, concerns, unresolved questions, and responsible parties.
- Silence is not treated as agreement without notice. Consultation requests should include a clear question and reasonable response date. If no response is received, that fact should be recorded rather than translated into endorsement.
- Disagreement remains visible. A final recommendation may proceed with unresolved concerns, but those concerns should accompany it.
- External advice is documented. Advisory-board or industry feedback should be shared as evidence, not converted into an unexplained directive.
- Changes are traceable. Major revisions should identify what changed and why.
- Final reports name dependencies. No recommendation should appear fully implementable if it depends on another committee, staffing, funding, facilities, or curricular approval.
Transparency does not require every exploratory conversation to include all six committees. It requires that consequential assumptions and emerging decisions become visible while they can still be changed.
14. Recommended Immediate Actions
- Appoint one liaison from each committee.
- Agree on the three communication levels: inform, consult, and joint recommendation.
- Create the shared folder structure and decision log.
- Ask every committee to produce a two-page current-state and input brief before final recommendations begin.
- Establish the AI specialization as a formal joint workstream between Coding and Specializations.
- Schedule monthly liaison checkpoints.
- Require an impact review before any committee proposes a new required course, specialization, prerequisite, portfolio milestone, or facility experience.
- Set a shared date for draft exchange that occurs well before final committee reports are due.
Working Conclusion
The committees do not need to surrender their individual charges or conduct all work collectively. They do need clear interfaces.
The Specializations Committee depends on the others for foundational coding, portfolio structure, facility capacity, introductory preparation, and career evidence. In return, the other committees need concrete specialization use cases so that they can design coding, portfolios, labs, introductory courses, and professional pathways around plausible student journeys rather than abstract assumptions.
The intended sequence is:
Shared definitions and current-state evidence → committee input briefs → provisional specialization cases → cross-committee impact review → pilots and feasibility work → coordinated recommendations
That process preserves focused committee work while making it difficult for a consequential decision to remain hidden until it has already constrained everyone else.