14.1
Bound the Task to Information Discovery and Verification
A campus dish system offers a concrete design connecting the two anchor articles. Its purpose is to find known information, related images, and unresolved issues for a stall's dish version, rather than decide what a student should eat. Questions may concern records mentioning chicken, possible matches for an image, or whether same named products share a version. They require relations, visual identity, and evidence. Outputs should state sources, time, and unknowns instead of treating a common recipe as an actual canteen ingredient list.
Requirements can collect real student and staff questions and classify precise lookup, ingredient discovery, image matching, feedback themes, and conflicts. Each needs acceptance criteria. Questions unsupported by records should request current information or stall confirmation. Clear scope makes technology selection easier: global communities and visual models are not needed for every request. A useful minimum system can cover a few stalls on specified dates while closing update and correction loops. The later simulated records test information logic and describe no actual campus food service.
14.2
Model Dish Versions and Observation Sources
The model should distinguish a dish concept, a stall product, and a product version. Kung pao chicken as a concept may connect to common preparation, the item sold by stall A is a product, and its recipe effective on a date is a version. Ingredient relations should attach primarily to versions rather than permanently to names. Menus, staff confirmations, photographs, and reviews produce different observations. Suspected visible ingredients should not overwrite confirmed lists, and taste reviews should connect to experience events instead of becoming timeless properties.
The model handles change and disagreement. An old photograph remaining after a recipe update creates a temporal mismatch rather than a reason to merge evidence. A known capture date without a known version can remain unresolved. Renaming does not necessarily change identity, and identical names do not guarantee identity, so stall, time, and management records matter. Staff interfaces should support version updates, attribute confirmation, and image withdrawal. User views may simplify presentation while underlying evidence remains complete. Users receive clear current information and maintainers retain its history.
Original design
14.3
Fuse Text Images and Human Confirmation
Menu extraction identifies names, ingredients, and preparation while preserving source locations. Image processing first checks quality and product association, then proposes ingredient categories and regions. Fusion compares identity, version, and semantic conditions, treating agreement as support and disagreement as a review item. Images cannot establish the absence of invisible seasoning, and text extraction must preserve negation. Human confirmation should remain a separate record with explicit scope, such as confirming a published ingredient description without claiming verification of every processing step.
Rules can automate low risk matches while high impact ambiguity receives review. Explicit product identifiers may match current menus automatically, while unclear images and conflicting ingredients remain candidates. A review interface can show text, regions, and older versions together. Confirmations generate queryable views while preserving original candidates for error analysis. Sampling should cover stalls, dish categories, and camera conditions rather than only clear photographs. The goal is manageable evidence rather than converting a detector score directly into trust. Models discover clues; confirmation rules determine which clues enter current knowledge.
14.4
Choose Retrieval Routes for Different Questions
Precise product questions first retrieve current versions and confirmed attributes, then return menu or confirmation records. Ingredient discovery traverses from ingredients to products while separating confirmation, textual mention, and visual candidates. Image matching generates candidates before checking stall and time; missing context can lead to a candidate list rather than one identity. Feedback themes can summarize review events but must state sampling periods and coverage instead of treating a few comments as all students' views. Routes share evidence identifiers without requiring identical algorithms.
Interfaces should expose information status. A record mentioning chicken differs from confirmed absence of an ingredient, which requires explicit exclusion evidence. Conflicts can show both sources and dates pending confirmation. Missing retrieved edges should not become absent attributes, and personal taste reports should not become objective product facts. Global comparisons should first define comparable stalls and dates. Without matched information, rankings should remain limited. This applies graph organization to information gaps without generating certainty beyond the sources.
14.5
Data Operations and Feedback Theme Analysis
A campus application requires continuing menu and image maintenance, not one graph build. Resource manifests can update daily or when changes occur, with staff confirming current versions and student corrections entering review. Frequency should follow actual change rather than repeatedly processing unchanged files for apparent real time operation. Feedback categories can separate incorrect information, mismatched images, outdated versions, and experiences, routing each to responsible people. Time from discovery to correction becomes a maintenance measure.
Theme analysis can reveal recurring issues such as stale images or missing attributes, while repeated submissions should not amplify one event. Aggregate independent events over time and preserve minority views. Operational analysis describes patterns in records but cannot infer causes from comment cooccurrence. High evening order volume and long waits suggest an association to investigate, not proof that volume explains every delay. Improvement decisions require staffing, equipment, and process evidence. The graph organizes these investigation routes and helps staff ask better questions rather than replacing observation and judgment.
14.6
Pilot Acceptance and Conditions for Expansion
A pilot can cover a few stalls, fixed dates, and frequent questions. Acceptance checks correctness, traceability, visible conflicts, and effective updates. Staff and students can perform search tasks while measuring time, errors, and understanding of uncertainty. Faster lookup is insufficient if the interface makes every attribute appear confirmed. Unanswerable cases should test guidance toward missing evidence. Automated measures, human task outcomes, and maintenance effort belong in one assessment.
Before expansion, verify that identity rules, ontology, and update processes still apply. Vendors differ in naming, image quality, and ingredient disclosure. Add deliberately different stalls as a transfer test rather than only similar data. Quality declines should be traced to insufficient evidence, ambiguous identity, or unsustainable processes. Stopping conditions can include unresolved critical errors, persistently stale versions, or inadequate sources, leading to narrower answer scope. A trustworthy application works consistently within a defined range and expresses its boundaries. Expansion should follow measured performance in the new range rather than the number of graph nodes already accumulated.