Join the design team.
Earn the architecture.
One campus case, six engineering decisions. Each activity reuses the artifact built before it, so the communication choice is the end of a reasoning chain — not a technology quiz.
Rule: use your current intuition first — no searching yet.
They do not give you answers. They bring needs, evidence and incidents that change what the system must do.
Build a deliberately diverse test set.
You do not need to classify everything. Map four cases that seem meaningfully different, spanning at least three domains. The purpose is to make the later IoT definition survive difficult examples rather than one familiar use case.
Use your test set to discuss.
Start from the four cases you selected and the boundary case you marked. Your teacher will then compare the class reasoning with a broader landscape.
Environmental observability across campus.
This dossier is the evidence you are allowed to treat as given. Everything else is an assumption to expose, not a fact to invent.
You can review the design your group defended at STOP 2, but you cannot silently rewrite history. If later evidence invalidates an assumption, record the resulting change explicitly instead.
Build a baseline design from the evidence available now
Invent the components yourself. Name roles or functions, not products or protocols. Then describe what information flows between them.
Architecture canvas
Drag components. Arrows appear when you add information flows.
You decide what belongs here.
Architecture · phone view
The graph is generated automatically from your components and information flows. You do not need precise drag-and-drop on a phone.
Add components and flows to generate the graph.
Edit / reorder components
Connect the components
Write what is exchanged, not the protocol used.
Which unresolved assumption could most change your baseline?
Choose one. You are not resolving it yet; you are making the uncertainty visible so later evidence can challenge it.
↗Challenge me · Architecture under attackSame objective, less guidance. Try it before opening support.0/3 support
Use your architecture to discuss.
Your architecture is reproduced below so the group can point to concrete choices during discussion.
What does the system actually know after it sends a command?
Keep the monitoring design. Follow just one ventilation command. Each step asks what the available evidence really proves; the control-loop model appears only after those distinctions have been made.
CO₂ is high. The service commands ventilation to 60%.
The controller returns a digital acknowledgement (ACK): it confirms message receipt or handling, not the physical result. The damper may still be mechanically jammed. A human operator must be able to supersede automation.
Observation and control create different flows.
Use the loop below to distinguish telemetry, command, acknowledgement and physical-state feedback.
Rank the system, then challenge that ranking on one real flow.
Choose only the three constraints that dominate the campus design overall. Then test one specific baseline flow separately. The comparison matters more than compiling a long list of constraints that merely “apply”.
Choose only the three constraints that would most change the campus communication design if they were violated. You are ranking design pressure, not listing everything that matters.
Would one real flow keep the same Top 3?
Choose one arrow from the defended baseline and give that flow its own three priorities. The point is to expose where a system-wide ranking hides a local difference.
We are not sure what a “requirement” means here
Choose one arrow in your architecture. Ask what would make that communication fail to satisfy the application: too far, too slow, too much data, too much energy, too many devices, no infrastructure, and so on.
↗Challenge me · Two flows, different evidenceTest whether a second flow forces a different priority set.0/3 support
Use your priorities to discuss.
Your selected dimensions and priorities are shown below. Use them as evidence rather than relying on memory.
Compare five communication families.
Do not choose yet. For each family, look at the same four things: distance/context, traffic, device constraints and required infrastructure. Also look at the small architecture chain: it shows who talks to whom.
Five families, five different system implications
There is no universal winner. The useful question is: which one fits the deployment we actually have?
Plain-language glossaryOnly open this if a word blocks you.
Choose a suitable technology for any three cases.
For each case, choose the family that seems the best fit among the proposed options. Feedback appears immediately. You do not need to find a “perfect” technology — just connect the deployment facts to the technology characteristics.
Optional reference · inspect any family in more detailUse this only if you want the technical vocabulary.
What can we defend for the campus with the information we actually have?
Choose a position, then identify one missing deployment fact that could still change it. There is no commit button: you can revise both choices at any time.
Coverage, exact placement, power/maintenance constraints and reporting cadence are still partly unknown. Do not invent them to force a technology choice.
One communication family everywhere, a mixed design, or not enough evidence yet?
More than one position can be defensible. What matters is whether the position matches the facts currently available.
Defend the campus communication decision — and its validity domain.
Use the technology comparison, the campus facts and the missing information you identified. The goal is not one universal winner; it is a decision whose important conditions are visible.
How would you classify the communication path you are carrying into Session 2?
This small handover does not change your design. It gives Session 2 a structured reference to the communication path you have just defended.
Before rereading anything, retrieve it.
Five quick prompts. Think first, then reveal. This is not graded.
Need → responsibilities → architecture & flows → control evidence → requirements → technology comparison → campus facts → defended campus decision.