01 / Decisions
Work & Learning
Turn complexity into choices that can be understood, tested, and used.
Cornell MEng and NUS MiM form two parts of the lens here: systems and engineering meet strategy and management.
The interest is not complexity for its own sake. It is the discipline of defining a problem, making constraints visible, and carrying evidence toward a useful decision.
Editorial lenses
A decision-oriented practice
- 01
Frame the system
Start with relationships, constraints, and the decision that actually needs to be made.
- 02
Separate signal
Distinguish what the evidence supports from what remains assumption or interpretation.
- 03
Make it usable
Translate analysis into a choice another person can inspect, challenge, and act on.
Representative thread / academic case study
Kopi & Co: three outlets, one Monday decision
An exploration of how a fixed dataset can be structured into an operating view, then used to reason about one constrained decision.
Read the case studyLJL / DECISION THEATRE
Your turn to make the call.
Take a Monday meeting brief. Choose a focus, open the evidence and decide what comes next. Then return to the original work and inspect the reasoning.
NUS / NEGOTIATION / 2026
A strong fallback. A narrower conversation.
Revisit a seller-team negotiation and the role of alternatives, price and complete offers.
PROJECT ROUTES / BEGIN WITH A QUESTION
See the work. Follow the thinking.
Choose a project, read its context, follow the process and try a related exercise. Search in either language to find a question that interests you.
9 routes / Reading: Kopi & Co
NUS / Digital transformation / 2026
What can these records help someone decide?
Start with the submitted interface, follow the choices behind its three screens, then try making a Monday operating decision yourself.
- Inspect the original↗
Read the entrance screen alongside its context.
- Follow the process↗
Trace the meeting questions into the three-screen structure.
- Make a decision↗
Choose an action and return to the evidence in the review.
The team prototype, my individual branch and the later website exercise have different data scopes.
Work experience / A requirements retrospective
Can someone else implement and check the request?
Follow a business request through definitions, fields, exceptions and acceptance examples. Then change a rule and see which paths move with it.
- Read the context↗
Understand the roles and the scope of the reconstruction.
- Trace a requirement↗
Connect the request to fields, behaviour and acceptance.
- Test a change↗
Compare normal, boundary and incomplete-input examples.
The examples are a later reconstruction of the working method, grounded in the roles described in my CV.
Cornell / CUSD / Sustainable Education
Who else does a design change affect?
Read the school concept through community needs, design, handoff and maintenance. A change rehearsal lets you follow one assumption across teams.
- Read the source work↗
Begin with the individual reports and their context.
- Follow the coordination↗
Inspect how community, sustainability and building work connect.
- Rehearse a change↗
Change an assumption and inspect the follow-up questions.
The case distinguishes my individual source work, team coordination and the proposed school concept.
Cornell / SYSEN 5400 / 2023
Which assumptions make an option look better?
Move from the needs diagram to the comparison of candidate designs. Then use a separate offer exercise to see how a change in priorities changes an evaluation.
- Inspect the diagram↗
Follow a need into a design goal in the original figure.
- Read the model context↗
Inspect candidate generation, comparison and limitations.
- Change a priority↗
Compare A and B under a different preference model.
The greenway team report uses generated architectures and simulated survey data; Offer Studio uses a separate fictional commission.
Cornell / CHEME/SYSEN 6800 / 2022
Does the implementation express the intended objective?
Begin with the incomplete course model and its zero-relocation result. The later bike lab makes the trade-off between relocation and unmet demand visible.
- Read the original result↗
Inspect what the report says about the implementation.
- Revisit the modelling choices↗
Open the project note and its retrospective checks.
- Inspect the objective↗
Change weights and compare the available plans.
The original implementation was incomplete. The website lab is an illustrative exercise, with its own inputs and assumptions.
Cornell / SYSEN 5930 / 2023
Does the plan have enough time, people and budget?
Read the service concept, then my cost-management contribution. A later scheduling exercise lets you inspect dependencies and the effect of changing task durations.
- Read the service concept↗
Understand the proposed delivery and collection process.
- Read my contribution↗
Follow scope, hypothetical budget and cost control.
- Try the schedule↗
Change a duration and trace the completion date.
The budgets are course planning assumptions. The website schedule and resource exercises use illustrative data.
Cornell / SYSEN 5740 / Cherry Street
What helps a first-time visitor take part?
Read the proposed district identity and digital presence. Then take the participation question into the F1 × LEGO studio and compare different first actions.
- Read the proposal↗
Inspect place information, arrival and digital connections.
- Revisit the design work↗
Read the contribution and original-work notes.
- Compare first actions↗
Try play, building and collecting in a different case.
Cherry Street is a design proposal. The linked participation studio extends a different project as an editorial comparison.
NUS / Product & Brand Management / 2026
Can someone participate before knowing the sport?
Follow my F1 × LEGO Quick Take from a first encounter to a product portfolio and the drivers’ parades. Then choose how a newcomer might begin.
- Read the Quick Take↗
Follow the original presentation’s argument.
- Follow the sources↗
Inspect the presentation and supporting public material.
- Choose a first encounter↗
Compare what play, building or collecting asks of a newcomer.
The analysis follows the individual presentation; the three-route studio is a later website extension.
NUS / El-Tek negotiation / January 2026
Which other condition could change the conversation?
Begin with the seller-team reflection, then revisit a real purchase in Bugis. Offer Studio gives the reader a fictional package to compare across several terms.
- Read the team reflection↗
Revisit price, alternatives and the other side’s priorities.
- Meet the everyday example↗
Read how buying two bags became part of an offer.
- Compare complete offers↗
Pin A and B, inspect the terms and switch priorities.
The classroom simulation, Bugis purchase and fictional offer model are separate experiences.
THE ORIGINALS / INTERFACES · MODELS · IMAGINATION
A closer look. A fuller story.
Nine pieces across three rooms. Inspect an original, compare two works, then follow the source and case.
Enter the original-work exhibition ↗CASE COMPARISON / METHODS SIDE BY SIDE
Different projects. What carries across?
Choose a question and read the three cases side by side. This is a retrospective comparison of the work, with a route into the material behind each case.
Frame the question
What can this row support?
The initial outlet-week data could guide attention to an outlet. A product-line decision required more detailed evidence.
Inspect the unit of analysis before designing a recommendation.
What should happen, for whom?
A request becomes easier to implement when the actor, input, condition and next owner are explicit.
Put the expected behaviour beside a concrete example.
Whose need does the concept answer?
Community, building, sustainability and budget perspectives affect whether a school concept is feasible.
Read a design choice alongside the need it addresses.
Organise the evidence
Keep the versions distinct.
504 × 15 describes the initial academic data. The final group artifact contains 3024 × 22 synthetic product records; the versions have different identifiers.
Use each version for the questions it can answer.
Connect the deliverables.
A field dictionary defines the inputs. Rules explain the route. An interface makes the behaviour visible, and acceptance examples specify the expected result.
Trace the same condition across the documents.
Separate team and individual work.
The team produced design and reporting work. My SYSEN 5190 plan is a separate individual contribution organising scope, milestones and management activities.
Read the role and authorship alongside each deliverable.
Handle a change
A new schema changes the question.
Moving from outlet-week rows to synthetic product rows changes the available detail. Repeated outlet totals require care before aggregation.
Recheck identifiers, row meaning and totals when the version changes.
One unit can change the route.
The fictional 500 boundary and the 501 example show why a small wording change matters. An exception record cannot replace required fields.
Check the boundary, exception path and incomplete inputs together.
A change travels across teams.
The hypothetical rehearsal explores how a cost assumption, maintenance responsibility or user need could affect related work.
Identify the affected design, budget, version and review criteria.
Check the judgment
Can someone explain the recommendation?
Read the screen, the evidence behind it and the limits of the dataset together. A polished interface still needs an interpretable basis for action.
Follow a recommendation back to the supporting data.
Can someone reproduce the check?
Normal, boundary, exceptional and incomplete-input cases give business and development teams specific outcomes to discuss.
Compare the expected route with the observed behaviour.
Does it conform—and does it fit?
Verification checks conformance to requirements. Validation asks whether the concept can meet the needs it was designed for.
Review the criterion and the underlying need together.
Work case 02 / From request to acceptance
From a request to a shared understanding.
A working-method case grounded in my experience at Hangzhou Huizhi: connecting requirements, fields, prototypes and acceptance.
Read the second work case ↗Work case 03 / Cornell · Sustainable education
Designing a school as a system.
Three semesters with a 34-member interdisciplinary team. My work in community, sustainability and building integration, with an original-work reader, relationship map and change rehearsal to explore the connections.
Open the case & system map ↗PROJECT NOTEBOOK / CITIES, MODELS & EXPERIENCE
Open three city projects.
Greenway candidates, bike rentals and returns, and the digital presence of a district. Read the original-work retrospective, then compare three-station allocations, costs and price thresholds.
Open the city-systems notebook ↗NUS / PRODUCT × FORMULA 1
From grid to bricks.
A personal F1 × LEGO brand study, with three ways to inspect a newcomer’s first encounter.
NEGOTIATION × SINGAPORE / AN INTERACTIVE STUDY
What matters besides the price?
Explore 45 packages and pin two offers. Follow a classroom reflection into a hands-on offer studio.
Put the terms on the table ↗BON APPÉTIT / SYSEN 5930
How does a delivery idea become a work and cost plan?
Open my cost-management chapter, then compare planned work, completed work and actual spend in the progress desk.
Open the service notebook & experiment ↗Project fieldbook / Across courses & roles
Different problems. The same curiosity.
From an engineering environment to service delivery, an optimisation model to a district’s identity. These completed projects and roles gave me different ways to practise understanding needs, organising information and shaping proposals.
7 projects & roles
Cornell · SYSEN 5400 · Spring 2023 · Team researchA greenway as a system
Pedestrian-greenway design brings stakeholder needs, operational choices and system performance together.
Contribution, deliverable & reflection＋
My contribution
I applied systems architecture and optimisation concepts, using Python and R to generate and analyse randomised datasets and support design recommendations.
Deliverable
System analysis, generated datasets and design recommendations.
Notes from the original work
Pedestrian Greenway Optimization System · 17 May 2023 · §§3.2.3, 3.5 & Conclusion
The team report describes generating 10,000 distinct architectures, checking constraints and comparing candidates with Pareto and fuzzy-Pareto analysis. It connects stakeholder needs to decisions, metrics and utility functions.
Its conclusion also identifies the dependence on simulated survey data and the need for observations on the ground. I would carry that qualification into any later use of the framework.
Continue in the project notebook ↗Process & perspective
This project brought systems architecture and optimisation into a setting people experience on foot. The analysis used generated data, so the relationship between a design choice and a performance measure matters as much as the best value returned by a model.
Looking back, I would put the assumptions beside each recommendation: whose journey the measure represents, what the generated data allows us to test, and which conclusions would need observations from the actual site.
IF I REOPENED THIS TODAY
Keep a route from the assumption back to the street.
If I reopened the greenway work, I would separate generated inputs from site observations before comparing designs. The useful next step is to find which recommendation depends most on something that has not yet been measured.
- Mark which demand and behaviour inputs were generated.
- Change one assumption while keeping the comparison conditions fixed.
- List the observation that would most help distinguish the alternatives.
Looking back, I would askWhich performance measure captures the experience of using the greenway, and how sensitive is a conclusion to the generated data?
Cornell · SYSEN 5930 · Fall 2023 · Team projectPlanning a delivery and service process
A service-improvement proposal also needs an executable plan: responsibilities, work, time, cost and risk.
Contribution, deliverable & reflection＋
My contribution
I co-developed a project management plan covering stakeholders, needs-to-goals traceability, organisation, work breakdown, schedule, labour cost, budget and risk.
Deliverable
A team project management plan for a delivery and service process.
Notes from the original work
Team8_BonAppetit_SYSEN5930_Assignment5_Word · Part 5: Cost Management Plan · Jinglin “Ronaldo” Li
The assignment identifies me as the author of the cost management plan. The proposed service combined fixed delivery points and nearby collection, with unmanned delivery considered as a possible extension.
In that section I questioned whether the original budget matched the proposed scope, then used an explicitly hypothetical expanded budget to discuss cost control, earned-value measures and reporting cadence. Those were course planning assumptions.
Continue in the project notebook ↗Process & perspective
The team plan connected stakeholder needs to goals, then to responsibilities, work packages, schedule, labour cost, budget and risk. A proposed improvement had to find its place in that delivery plan.
My reflection now is about the joins: a task can look clear on its own while its handoff remains vague. I would review the link from each goal to its owner, completion check and dependent work, then ask what a delay changes elsewhere. The delivery experiment on this site now adds finite crew capacity: an activity can be ready by its dependencies and still have to wait for people.
IF I REOPENED THIS TODAY
Review the handoff where a plan becomes work.
I would take one activity through its predecessor, assigned crew and completion check, then change the available capacity. That makes it easier to see whether the next delay comes from the work network or from people being occupied.
- Match the proposed improvement to a work package and owner.
- Check what evidence lets the next activity start.
- Re-run the same order with a different crew capacity.
Looking back, I would askCan every proposed improvement be traced to an owner, a piece of work and a way to check completion?
Cornell · CHEME/SYSEN 6800 · Fall 2022 · Team courseworkBikes, docks and competing objectives
A station-rebalancing model connecting relocation costs with unmet rental and return demand.
Contribution, deliverable & reflection＋
My contribution
I participated in formulating an academic model of bike allocation, station capacity, relocation costs and unmet demand.
Deliverable
An academic model formulation and discussion of an incomplete implementation.
Notes from the original work
NYC CITI Bike Parking, Bike Availability Optimization and Profit Maximization · 21 November 2022 · Model Introduction, Model Implementation & Conclusion
The original cover identifies CHEME/SYSEN 6800. The model considers relocation costs together with penalties for unmet rental and return demand, using assumed supply and demand at stations.
The report explicitly records an incomplete implementation: the penalty terms were not correctly connected, so the model returned zero relocations. This makes checking the implemented objective an important part of the retrospective.
Continue in the project notebook ↗Process & perspective
The model formulation connected bike availability, station capacity, relocation costs and unmet rental and return demand. Those objectives meet at a very ordinary moment: a person arrives to borrow a bike, or needs an empty dock to return one.
I would now check how the objective and constraints are implemented, then ask what a proposed allocation would mean for someone trying to use the network.
IF I REOPENED THIS TODAY
Put the objective beside both ends of a trip.
Before extending the incomplete implementation, I would verify a small case by hand: someone needs a bike at one station and an empty dock at another. That simple check can expose a mismatch between the objective and the user situation it is meant to represent.
- Check available bikes and empty docks before and after relocation.
- Keep unmet rental and return demand distinguishable.
- Compare relocation effort with the remaining service gap.
Looking back, I would askWhat does an improvement in the objective mean for someone trying to find a bike—or an empty dock?
Cornell · SYSEN 5740 · Design-thinking projectA digital presence for a place
A website and social-media concept for Cherry Street, alongside a proposed Business Improvement District.
Contribution, deliverable & reflection＋
My contribution
I developed design-thinking concepts for the district’s digital presence, stakeholder engagement and place branding.
Deliverable
Digital-presence and place-branding concepts.
Notes from the original work
Cherry Street BID Intro, Web/Social Media Branding and Interaction · course presentation
The presentation proposes a future Cherry Street Business Improvement District. Its digital concept covers area information, a business map, imagery, directions and links between social media and a website.
It considers starting with an existing visitor-information site, then developing a standalone presence as the district develops. The material presents a proposal, rather than a record of a launched district website.
Continue in the project notebook ↗Process & perspective
The design-thinking proposal explored a website, social media and stakeholder engagement for Cherry Street, including the possibility of a future Business Improvement District. The subject was a place with its own participants and identity, which makes the question broader than the appearance of a page.
When I revisit the concept, I would follow a visitor’s questions: what is here, why would I come, and where do I go next? I would also ask who can keep the information useful over time. Presentation and upkeep belong in the same conversation.
IF I REOPENED THIS TODAY
Design the next visit as carefully as the first.
I would walk through the concept as a visitor, then as someone responsible for keeping it accurate. A district page needs a route into the place and a workable way for its participants to maintain the information.
- Follow a visitor from discovering the district to choosing a next step.
- Identify the owner of each piece of changeable information.
- Decide how an outdated item would be corrected or removed.
Looking back, I would askWhat would help a visitor understand the place, and what would make its local stakeholders want to participate?
Chengdu Zhonghuan · February–December 2025 · Internal operations & business developmentFollowing a request through an operation
Operational review, warehouse and material-planning improvements, and coordination across manufacturing functions.
Contribution, deliverable & reflection＋
My contribution
I analysed three fiscal years of operating information, supported process improvement, tracked progress across production, procurement and warehousing, and assisted customer visits and project discussions.
Deliverable
Management analysis, progress tracking and organised customer and project information.
Process & perspective
This role brought operational review and follow-up together. I analysed three fiscal years of operating information, supported warehouse and material-planning improvements, and coordinated work across production, procurement and warehousing.
Customer visits, project discussions and business-development travel added another view of the same operation. Looking back, I would trace a customer question through the internal information and follow-up it needs: what was learned, who needs it, and what has to happen next.
IF I REOPENED THIS TODAY
Make the next action travel with the information.
For an operating or customer question, I would review whether the same terms and dates mean the same thing across the people handling it. The handoff should carry enough context for the next person to act without rebuilding the whole conversation.
- Agree on the meaning and date of the status being discussed.
- Name the next responsible role and the information it needs.
- Record what evidence would close the follow-up.
Looking back, I would askCan a customer or operating issue be followed through the information, owner and next action it needs?
Honeywell · Chongqing · June–August 2023 · Product engineering internshipA virtual environment that can be tested
A virtualisation environment supporting Honeywell Experion, developed with a four-member engineering team and six internal stakeholders.
Contribution, deliverable & reflection＋
My contribution
I collaborated on its design, implementation and testing, completing a virtualisation testing project within five days.
Deliverable
A virtualisation test project. My CV records estimated setup/training savings of 15–25 hours and an estimated 10–20% hardware-utilisation improvement.
Process & perspective
The virtualisation work combined design, implementation and testing with a four-person engineering team and six internal stakeholders. Completing a test project within five days gave the work a concrete delivery point.
The CV’s time-saving and utilisation figures are estimates. In revisiting the work, I would want a comparable baseline for setup and training, the same workload across environments, and a clear record of which hardware resources were counted.
IF I REOPENED THIS TODAY
Give an estimated benefit a repeatable comparison.
I would turn the CV’s estimated benefits into a comparison plan: the same workload, a documented baseline, and separately measured setup and training time. The aim would be to learn how much of the estimate holds under comparable conditions.
- Record the workload and hardware counted in each environment.
- Separate configuration time, training time and repeated work.
- Check that the comparison uses the same utilisation definition.
Looking back, I would askWhat baseline and test conditions would make those estimated benefits comparable and repeatable?
Siemens · Shanghai · June–August 2021 · Product design internshipRequirements become a first interface
An early web-application concept for a building-management use case, with changing client requirements.
Contribution, deliverable & reflection＋
My contribution
I gathered and translated requirements, built early HTML/CSS interface prototypes, and prepared client-specific product statements and design documentation while coordinating scope and timing.
Deliverable
Early interface prototypes, product statements and requirements documentation.
Process & perspective
My work connected client requirements to an early building-management web application: gathering input, translating it into interface concepts, making HTML/CSS prototypes and preparing product and requirements documents.
The part I would revisit is how a change travels. A revised request can affect a screen, a product statement, the scope and the schedule at once. Keeping those descriptions consistent makes the prototype a more useful basis for the next discussion.
IF I REOPENED THIS TODAY
Follow one revised request across every representation.
I would choose a changed requirement and follow it through the interface prototype, product statement and delivery plan. The review becomes concrete when a screen can be linked to the reason it changed and the check that would show it is ready.
- Identify the current requirement and the version it replaces.
- Find the screens and product statements affected by the change.
- Agree on a visible acceptance check and the delivery consequence.
Looking back, I would askWhen scope changes, which screen, requirement and delivery expectation need to change together?
Experience and participation follow my August 2026 CV, with original-work notes for four course projects. The Citi Bike course number follows the original report cover. Reflection questions were written for this fieldbook. Read the CV ↗
Working method / From policy to acceptance
A requirement should be something you can test.
In my requirements work at Hangzhou Huizhi, I translated policies and stakeholder needs into workflows, fields, calculation rules, interface mock-ups and acceptance criteria. This independently reconstructed example shows how those pieces connect.
Independent demonstration: the 500 threshold and all inputs are fictional examples, not company policy, business records or deployed-system screens. The model demonstrates routing; it does not approve or submit a real request.
Change a condition. Follow the route.
The example fields and routing conditions are satisfied. Human review remains the next step.
Acceptance examples / Make expectations visible
Turn “it should” into a reproducible check.
- 01
350, purpose present, no exception
Ready for standard review - 02
800, purpose present, no exception
Route to exception review - 03
800, purpose present, exception attached
Ready for standard review - 04
350, purpose missing
Complete or correct the request
INFORMATICS → SYSTEMS → MANAGEMENT
Different settings. Familiar questions.
Informatics, systems engineering and management; everyday life and games too. Revisiting these experiences, I keep comparing the evidence, the timing of a test and whether someone else can use the result.
6 notes · Revisited October 2026
Work / RequirementsCan someone else carry the requirement forward?
Connect a request to fields, rules, exceptions and acceptance checks.Open the reflection＋
A broad business request becomes useful when the next person can implement and verify it. My Huizhi experience is the starting point; the linked example is an independent demonstration.
A check for next timeCan a reviewer explain who may do what, and what happens when the ordinary path fails?
Inspect the workflow ↗NUS / Kopi & CoWhat can the current data actually decide?
Use the outlet-week data to prioritise outlets and guide a labour review.Open the reflection＋
My original 504-row branch contained outlet-week evidence. A product withdrawal decision needed product-level evidence. The final group artifact added a different, richer synthetic dataset.
A check for next timeMatch the level of the decision to the level of the evidence before adding another recommendation.
Read the project reflection ↗NUS / Classroom challengeWhen should the plan meet a real test?
Looking back at the 21 cm tower: measure and test earlier.Open the reflection＋
We chose option 3A and reached 21 cm. Looking back, an earlier measurement could have given us more time to adjust the structure.
A check for next timeAsk for feedback while a change is still possible.
Read the classroom note ↗FFXIV / FishingWhat belongs to preparation, and what belongs to chance?
Treat setup, the window and the final bite as different parts of the attempt.Open the reflection＋
Skyfrond took several windows. Completing the preparation opened an opportunity; it did not settle the outcome.
A check for next timeReview the part of an attempt that can actually be improved, then prepare for the next window.
Read the Skyfrond story ↗Singapore / Dinner plansWhat do I need to buy, given what I already have?
Start with the ingredients in the cupboard, then work out portions.Open the reflection＋
The tomato-and-egg and butter-prawn plan began with butter, eggs and one tomato already available. Cost and avoiding waste were part of the question.
A check for next timeDoes the shopping list fit the meal and the quantity I can use?
Read the kitchen note ↗This site / Product designDoes the finished page work for the person reading it?
Use actual feedback to refine small type, theme contrast and Chinese copy.Open the reflection＋
Friends noticed awkward Chinese. I noticed labels that were too small. Those observations became specific design and editing work.
A check for next timeRead it in both languages, at small widths, and in both themes.
Read the design note ↗Learning network / People, systems & management
Follow an idea across disciplines.
Informatics, systems engineering and management are three strands in how I approach technology, business and execution. These are my editorial connections; the programme links provide each institution's own context.
- 01 / Indiana University Bloomington
Informatics
Technology makes more sense when its human and organisational context stays in view.
Official programme context ↗ (new tab) - 02 / Cornell University
Systems engineering
Connect stakeholder needs, system behaviour and the evidence used to verify a design.
Official programme context ↗ (new tab)My Cornell project case ↗ - 03 / NUS Business School
Management
Bring structured problem solving, digital transformation and organisational execution into the same frame.
Official programme context ↗ (new tab)
LJL / READING COMPANION
A term, an example, a way back.
Read a short explanation, connect it to a site example, then return to the question you were exploring.
Browse terms and examples3 terms in this pillar
3 matches
A baseline gives the comparison a starting point.Baseline
A comparison needs an agreed reference: what work was planned, for when, and at what cost. If that reference changes, keep the version visible.
In a site example
In the service-planning notebook, read planned value, earned value and actual cost separately. More money spent and more work completed describe different parts of the story.
Did the result change, or did the reference against which it is judged change?
The longest dependency chain sets the pace.Critical path / Total float
In the basic critical-path model, task durations and dependencies determine the earliest project finish. Total float is the delay an activity can absorb without moving that finish, under those same assumptions.
In a site example
The delivery experiment first calculates the dependency network. Its crew extension then adds a separate constraint: a task may be ready to start while every crew is occupied.
Is the wait caused by unfinished predecessor work or by unavailable people?
Check the requirement, then the actual need.Verification & validation
Verification asks whether the result meets its specified requirements. Validation asks whether it serves the intended use and user needs. Both belong in an acceptance discussion.
In a site example
For an education-space concept, a design can satisfy a written specification while leaving an operating question unresolved. The sustainable-education case follows design coordination through to those later questions.
What would demonstrate conformance, and who would judge whether the result is useful?
LJL / WATCH · READ · EXPLORE
Stay with the question a little longer.
Move between original material, public lectures and the questions inside each case.
Sources reviewed · Companion sources and viewing questionsMIT OpenCourseWare / EN / 2020
Follow the feedback, beyond one decision.
This MIT workshop introduces system dynamics. It offers another way to examine delays, accumulated effects and feedback around the urban-systems notebook. The published recording omits the Fishbanks simulation for copyright reasons.
Which consequence arrives late enough to escape the first dashboard?
MIT / James E. PaineCornell University / EN
A design keeps meeting the world after handover.
Cornell’s introduction to sustainable design provides wider context for the built environment. Read it alongside the sustainable-education concept, then trace who would use, maintain and adapt a design over time.
Who inherits the operating work after the design team leaves?
Cornell / Design & Environmental AnalysisLJL / Group submission / EN + 中文导读
Go back to the original before changing the rule.
The Kopi case brings the published submission, screen evidence and authorship together. Compare the submitted view with the later decision theatre: a clearer control should still answer a real management question.
What evidence would justify changing a threshold rather than changing the display?
Published team material and case attributionExternal video players connect only when requested, with autoplay off. Closing or switching removes the current player.