An AI agent-based smart campus management platform

1 Introduction

Campus networks and digital service platforms generate extensive records of student connectivity, device access, wireless access-point (AP) associations, academic activity, and security events. These records naturally connect time, person, place, and device, yet they are commonly distributed across network management platforms, operational databases, spreadsheets, device logs, and manually prepared reports. Fragmentation limits traceability and makes it difficult for administrators to develop a coherent view of student activity, network conditions, and emerging operational risk.

The proposed platform addresses this problem through an integrated sequence of data ingestion, governance, trajectory analysis, dashboard presentation, AI-assisted interpretation, and report generation. Its scope includes campus network behavior, AP locations, building and zone semantics, spatial heat patterns, anomalous traffic, academic attributes, and institutional knowledge. Rather than treating these sources as independent administrative records, the design establishes a governed analytical foundation through which discrete observations can be transformed into interpretable activity trajectories, group-level mobility patterns, risk indicators, and decision-support products.

The project also responds to a practical limitation of conventional analytics systems: their dependence on specialized interfaces and technically trained operators. An AI Agent is therefore introduced as a controlled interaction layer. The Agent does not replace the underlying analytical services or authoritative data stores. Instead, it interprets a user’s request, invokes approved tools for trajectory, hotspot, ranking, and report queries, and combines those results with RAG-based retrieval from an approved institutional knowledge base. This approach is intended to make complex analysis accessible through natural-language interaction while retaining traceability, permission checks, and human oversight.

This manuscript reorganizes the research and technical content of an existing project proposal as a journal-style design paper. It defines the project objectives, research methods, system and data architectures, functional modules, security controls, expected outcomes, and limitations. It does not introduce an experimental protocol, report measured accuracy, or claim validated system performance.

2 Background and related work

2.1 Learning analytics and multisource campus data

International research on student behavior has developed from the related fields of learning analytics and educational data mining. Learning analytics generally emphasizes instructional intervention and educational decision-making, whereas educational data mining places greater emphasis on discovering patterns and improving computational methods. Their data sources and practical objectives nevertheless overlap substantially. Recent smart-campus work has extended this foundation by integrating Internet of Things infrastructures, digital twins, administrative automation, and campus information services [1–4].

Student behavior analysis has similarly progressed from static indicators such as grades and attendance toward heterogeneous behavioral evidence, including learning-management-system activity, network access, smart-card transactions, library use, and device connections. This transition supports process-oriented descriptions of participation, mobility, and resource use, but it also raises difficult questions about data definitions, cross-system identity resolution, quality control, and legitimate use. Campus management systems described in the source proposal illustrate an increasing interest in AI-supported reporting, student information services, and integrated management [5–9].

The source proposal characterizes related Chinese work as strongly application-oriented, with emphasis on smart-campus construction, digitally enabled vocational education, and AI-supported administrative systems. These studies reinforce the practical demand for unified governance and decision support, although their bibliographic details require independent verification before formal submission [10–12].

2.2 Trajectory reconstruction and spatiotemporal interpretation

Campus trajectory studies increasingly seek semantic interpretations rather than simple location displays. Access records, smart-card events, attendance observations, and network associations can be related to buildings, functional zones, and time periods to describe where activity occurs, how movement changes, and which routes or locations recur. Such approaches make it possible to progress from isolated connection points to dwell events, movement segments, frequent paths, group migration patterns, and context-aware activity profiles.

The present project adopts a lightweight alternative to GPS-based tracking. It reconstructs approximate campus trajectories by linking network access logs to AP MAC addresses and then mapping APs to buildings, zones, and coordinates. The method uses infrastructure already present on campus, but its interpretation must remain appropriately cautious: an AP association is an indirect observation of device connectivity, not a precise measurement of a person’s physical location. Short reconnections, handoff oscillation, inactive devices, shared devices, and incomplete AP metadata can all introduce uncertainty.

2.3 AI-supported analysis, agents, and RAG

Generative AI has expanded the design space for educational and administrative analytics from prediction and fixed dashboards toward natural-language explanation, human–AI collaboration, and conversational decision support. Studies of ChatGPT and related technologies in higher education have emphasized both possible service improvements and the need for trustworthy, human-centered deployment [13–15]. General-purpose agent benchmarks and recent agentic research further demonstrate the importance of tool use, multistep reasoning, and explicit task orchestration [16–18].

RAG is particularly relevant because it separates an institution’s governed knowledge resources from the language model and retrieves approved evidence at query time. In the proposed platform, retrieval is combined with structured analytical tools rather than treated as an unrestricted text-generation mechanism. The Agent can therefore answer institutional knowledge questions, explain a chart, or request a predefined data aggregation while returning citations or provenance information when available. Earlier campus chatbot and event-tracking systems provide a useful operational precedent, although the bibliographic details of several such records in the source proposal require verification [19–21].

2.4 Persistent problems and development trends

Existing research and applications still exhibit several recurring limitations. First, many systems focus on a single source or business scenario and do not integrate network logs, AP locations, academic data, anomalous traffic, and institutional documents within one governed model. Second, statistical displays and isolated warning rules are often not accompanied by explanations that connect an output to its spatial, temporal, and data-quality context. Third, conversational analysis, grounded knowledge retrieval, and automatic reporting remain unevenly integrated with conventional campus applications. Fourth, privacy protection, classification, authorization, auditability, and responsible human oversight are often described as requirements but are more difficult to operationalize across an entire platform.

The development direction is consequently moving from single-source analysis toward heterogeneous data fusion; from outcome prediction toward process interpretation and semantic trajectories; from passive visualization toward warning and decision support; from fixed interfaces toward agent-mediated analysis; and from technical feasibility toward accountable, privacy-aware governance. These trends motivate the integrated design developed in the remainder of this paper.

3 Project objectives and design principles

The overall objective is to design a comprehensive platform that integrates data acquisition, governance, behavior analysis, visualization, and intelligent decision support for a university campus. The platform is intended to support independent deployment by a single undergraduate, vocational, or applied institution and to evolve as additional systems and analytical models become available. It is not tied to the introduction of new positioning hardware; instead, it makes governed use of existing digital systems and network infrastructure.

The design is guided by six principles. First, multisource coherence requires common identifiers, time conventions, spatial codes, and quality rules across heterogeneous sources. Second, semantic interpretability requires every trajectory or hotspot to be connected to understandable building, zone, and time information. Third, security and privacy by design places minimization, desensitization, role-based authorization, and auditability within every data path. Fourth, modular scalability separates ingestion, storage, analysis, applications, and AI services so that components can be scaled or replaced. Fifth, human-supervised intelligence limits the Agent to approved tools and evidence sources and preserves human responsibility for consequential decisions. Sixth, operational usability provides dashboards, filters, reports, and natural-language access appropriate to users with different technical backgrounds.

The source proposal specifies the prospective technical indicators in Table 1. These values are design and acceptance targets, not measured results.

TABLE 1. Prospective technical and operational targets from the source proposal.

4 Research content

4.1 Multisource data acquisition and governance

The data-governance work begins with a source inventory and a canonical model. Candidate systems include network behavior management, academic affairs, student services, learning management, library, campus card, residence management, AP inventories, security devices, and institutional document repositories. Depending on the source, acquisition may use an application programming interface, database synchronization, batch file import, log collection, or event streaming. Each connection must be approved by the responsible data owner and limited to the fields required for the stated analytical purpose.

Table 2 translates the operational data-source table in the proposal. It distinguishes source cadence from analytical purpose so that the platform can apply source-specific validation and retention rules.

TABLE 2. Planned data sources, update modes, and uses.

Raw records are standardized through field mapping, timestamp parsing, MAC-address normalization, duplicate resolution, data-type conversion, spatial mapping, and controlled desensitization. Quality controls assess completeness, consistency, uniqueness, timeliness, and referential integrity. Both the raw-ingestion path and the cleaned-ingestion path are retained where policy permits, enabling traceability without allowing ungoverned raw data to leak into applications. The platform also defines exception handling for malformed records, late arrivals, duplicate events, missing AP mappings, and inconsistent identity fields.

The data model follows four layers: the operational data store (ODS) preserves authorized raw network details, security events, trap messages, and imported academic data; the dimension layer (DIM) maintains students, APs, buildings, zones, and knowledge documents; the detailed data warehouse (DWD) contains standardized, deduplicated, and mapped observations; and the data warehouse service/application data service layers (DWS/ADS) provide aggregates and analytical views for dashboards, reports, and Agent tools. This separation supports provenance, incremental processing, and efficient reuse.

4.2 Student trajectory reconstruction and spatiotemporal behavior analysis

Trajectory reconstruction links an authorized network-detail record to an AP MAC address, maps the AP to a building, zone, and coordinate, and orders the resulting observations by student and time. The processing pipeline filters handoff oscillation, very short reconnections, duplicate records, implausible durations, and unmapped or low-quality locations. It then constructs trajectory points and segments, estimates dwell events, aggregates visits by time window, and derives frequent zones and migration paths. The method produces an approximate network-derived activity trace and must not be interpreted as continuous or exact physical tracking.

At the individual level, the planned analysis includes trajectory playback, frequently visited zones, dwell patterns, high-frequency routes, connection rankings, and interpretable profile labels such as relative activity level or zone preference. At the group level, it includes time-of-day changes, building and zone heat, east/west or learning/living-area comparisons, and common migration paths. Academic data may be associated with these features only for approved purposes, under role restrictions, and without treating correlation as causation. Outputs are intended to support student services, resource planning, and carefully governed risk review rather than automated judgments about individuals (Figure 1).

4.3 Anomalous traffic detection and risk warning

The proposed warning mechanism combines anomalous network traffic, abnormal connection behavior, and unusual spatiotemporal patterns. Candidate evidence includes security-appliance alerts, SNMP trap messages, attack-type dictionaries, blacklists and whitelists, connection-frequency thresholds, short-interval data-transfer patterns, unusual access times, and exceptional activity in designated zones. Rule-based methods provide explicit thresholds and interpretable conditions; feature-based analysis can later be introduced when sufficiently representative, ethically governed, and manually reviewed labeled data become available.

Detected events are normalized into an event taxonomy with source, time, location, affected asset, attack or anomaly type, severity, confidence or rule provenance, and handling status. Related low-level events may be aggregated to avoid repetitive alerts. Warnings can then be presented through the management interface, dashboard, waterfall list, or an authorized notification channel. The intended workflow includes acknowledgement, assignment, investigation notes, status changes, and closure, so that warning performance can be reviewed in operational context.

The fusion of behavior and security evidence is intended to improve contextual interpretation. For example, a network alert can be shown with its relevant building and time window, while an unusual crowd pattern can be assessed alongside known events and operational schedules. This is a decision-support mechanism, not an automatic disciplinary or security determination. Human review, evidence provenance, and proportional response remain mandatory.

4.4 Data visualization and dashboard design

The visualization work uses a Vue 3 front end with ECharts and a map component to present trajectories, heat distributions, trends, rankings, reports, and warning events. The principal dashboard views are trajectory display, heat analysis, Agent-assisted interpretation, and anomalous-traffic analysis. A common layout retains stable contextual charts while the central map or analysis panel changes with the selected task.

Interaction features include a playback timeline, pause and time-window controls, linked chart filters, drill-down by building or zone, refresh indicators, and coordinated highlighting across maps and charts. Planned fixed visual elements include online-population trends, online AP counts by building, regional distribution charts, living-area versus learning-area comparisons, anomalous-traffic categories, severity filters, and a real-time event waterfall. Every analytical output should display its time range, filtering conditions, aggregation level, and data freshness so that users can interpret it correctly.

The design emphasizes legibility for both operational monitoring and briefing settings. At the same time, dashboards should avoid implying precision that the source data cannot support. Approximate trajectories, incomplete AP mappings, and delayed feeds must be indicated explicitly. Accessible color choices, text alternatives, consistent units, and exportable tables should be incorporated during implementation.

4.5 AI agent and RAG-based intelligent analysis

The AI component provides a natural-language entry point for data and knowledge tasks. Intended functions include obtaining a current data overview, identifying hotspot zones, ranking connections or frequent paths over a specified period, generating an authorized student profile, creating daily or weekly summaries and topical reports, answering institutional knowledge questions, and explaining charts or platform functions.

The Agent uses an explicit tool registry rather than direct, unrestricted database access. Planned tools include an overview query, hotspot query, frequent-migration-path query, single-student trajectory query, report-generation service, and RAG retrieval service. A request is first classified and checked against the user’s role and scope. The Agent then plans one or more permitted calls, validates required parameters, executes the tools, and composes a structured response from returned data. Tool outputs should include provenance and time-window metadata, and the Agent should refuse or escalate requests that exceed the user’s permissions.

The RAG pipeline includes document ingestion, review and publication status, chunking, embeddings, vector indexing, semantic retrieval, evidence ranking, and citation return. Unreviewed documents must not enter the production index. Retrieved passages are used to ground institutional answers, while structured tools remain authoritative for quantitative data. The interface should clearly distinguish retrieved institutional information, computed analytical results, and model-generated explanation. Multi-turn context should be minimized and protected, and consequential outputs should be reviewable by a responsible staff member.

5 Technical route and system architecture

The overall technical route follows five connected stages: multisource acquisition, data governance and layered storage, trajectory and behavior modeling, anomaly detection and warning, and visualization plus AI-assisted analysis. Figure 2 retains the business workflow from the source proposal.

5.1 Overall architecture

The platform separates presentation, services, middleware, data resources, and AI capabilities. The presentation layer contains the management interface, situational dashboard, and Agent interaction view behind a unified Nginx and HTTPS entry point. The service layer contains the Spring Boot business service, FastAPI/LangGraph Agent service, SNMP trap receiver, and scheduled-task service. Middleware includes Redis, Kafka, and controlled file storage. The data layer separates MySQL transaction and dimension data from ClickHouse trajectory details and analytical aggregates. AI services include model access, embeddings, vector retrieval, and the governed knowledge base.

This modular design supports independent replacement and scaling. Existing Quartz jobs may continue to run system-level tasks, while XXL-Job is proposed for business-level ingestion, aggregation, and reporting workflows. Interfaces between modules should use versioned contracts, authentication, input validation, timeout handling, and consistent observability (Figures 3, 4).

5.2 Data architecture

MySQL stores transactional records, reference dimensions, permissions, management data, and workflow state. ClickHouse stores high-volume trajectory details, hotspot aggregates, migration rankings, and report-oriented analytical results. Kafka buffers and distributes streaming inputs and decouples producers from downstream consumers. Redis caches frequently requested dashboard results and short-lived state. File storage retains authorized raw traps, controlled import files, institutional knowledge documents, and generated reports according to retention policy (Figure 5).

Table 3 presents the proposed update mechanisms. The frequencies are planning values and should be calibrated against source-system capacity, operational needs, and approved retention requirements.

TABLE 3. Planned update mechanisms and responsible components.

5.3 Application architecture

The application architecture comprises the business administration subsystem, dashboard subsystem, trajectory analysis subsystem, warning and recognition subsystem, report subsystem, Agent subsystem, data-ingestion subsystem, and knowledge-base subsystem. Their responsibilities are summarized in Table 4. Shared capabilities include identity and access management, audit logging, configuration, export control, task monitoring, and data-quality status (Figure 6).

TABLE 4. Planned application subsystems and responsibilities.

5.4 AI agent architecture

The Agent service is proposed as a FastAPI application orchestrated through LangGraph. A unified internal API provides access to the institution’s authorized model service. The Agent architecture contains an intent and parameter layer, a policy and authorization layer, a planner, the approved tool registry, an execution and validation layer, a response composer, and an audit trail. RAG services remain a distinct tool chain comprising document governance, embeddings, indexing, retrieval, and evidence return.

The architecture should prevent prompt text from becoming an implicit authorization mechanism. User identity, role, organizational scope, allowed student population, and field-level restrictions must be enforced by the underlying service on every tool call. Results should be structured before explanation, and generated reports should preserve query parameters, data time ranges, evidence sources, and responsible reviewers. Tool errors, missing data, or retrieval uncertainty should be reported rather than filled with model speculation.

5.5 Deployment architecture

Deployment is organized into access, application, data, and AI zones. The access zone contains Nginx, static resources, and the HTTPS entry point. The application zone contains multiple Spring Boot and Agent instances together with scheduled-job executors. The data zone contains MySQL, Redis, ClickHouse, Kafka, and file storage. The AI zone contains model-computing, embedding, and RAG retrieval services. Separate business and management network segments, firewall policies, authenticated remote access through a VPN or dedicated channel, monitoring, alerting, and cross-failure-domain placement are proposed for production use.

The recommended software environment in the proposal is shown in Table 5. Versions are implementation recommendations and should be reviewed against institutional support and security policies before deployment (Figures 7, 8).

TABLE 5. Recommended software environment from the source proposal.

6 Functional module design

The platform is designed for network-center administrators, institutional leaders and managers, student-affairs staff and counselors, security staff, data analysts, and knowledge-base administrators. Their core needs and typical interfaces are translated in Table 6.

TABLE 6. User roles, primary needs, and typical interaction modes.

6.1 Base data management

This module maintains authorized network details, AP coordinates and MAC addresses, buildings and zones, academic imports, knowledge documents, and anomaly-analysis configuration. Functions include filtered queries, controlled import, correction workflows, archival, attack-type dictionaries, severity rules, whitelist and blacklist maintenance, threshold policies, event status, document classification, review, publication, and index rebuilding. Inputs include spreadsheets, database synchronization, security logs, manual entries, and uploaded documents; outputs include standard dimensions, management registers, rule resources, knowledge indexes, and governed analytical data (Figure 9).

6.2 Trajectory analysis

This module retrieves network-detail records for an authorized student or group and time range, maps APs to spatial dimensions, filters reconnection noise and invalid observations, constructs points and segments, and produces dwell, route, and zone statistics. Outputs support map playback, chart analysis, rankings, and controlled Agent tools (Figure 10).

6.3 Heat analysis

The heat-analysis module aggregates activity at hourly, daily, weekly, or monthly scales and presents zone density, temporal change, regional shares, learning-area versus living-area patterns, and hotspot-building rankings. Potential applications include planning use of teaching buildings, libraries, dining areas, residences, and activity venues, subject to the limitations of network-derived presence data (Figure 11).

6.4 Warning and anomaly recognition

This module manages anomalous-traffic information, classifies attack events, applies severity rules, presents warning lists, and displays streaming messages. Its rule sources include security-device alerts, original SNMP trap logs, abnormal-connection thresholds, and authorized rules for designated zones. The interface must connect every warning to its source and handling state (Figure 12).

6.5 Statistical reporting

The reporting module prepares periodic and topical views for management and operational analysis. Planned reports include current data overviews, online-population trends, online AP counts, hotspot zones, route rankings, and anomalous-traffic summaries. Reports may be triggered manually, scheduled by XXL-Job, or summarized through the Agent. Controlled export to Word, PDF, or spreadsheet formats should preserve data classification, query scope, generation time, and access restrictions.

6.6 AI-assisted analysis

The AI module turns approved queries, hotspot analysis, profile generation, report preparation, knowledge retrieval, platform explanation, and chart interpretation into a conversational workflow for nontechnical users. It should return structured results, cite retrieved institutional evidence where possible, explain the applied filters, and avoid presenting model-generated inferences as source data (Figure 13).

7 Data security, privacy protection, and access control

Campus behavior and academic information can be highly sensitive. The platform therefore requires a formal data-governance basis before any production deployment. Data owners must define permitted purposes, minimum fields, lawful or institutional authority, retention periods, and user groups for each source. Direct identifiers should be separated from analytical identifiers wherever feasible, and outputs should use aggregation, masking, pseudonymization, or suppression appropriate to the task.

Authentication is centralized, and authorization follows role-based access control (RBAC) with additional scope restrictions where necessary. Permissions should cover menus, services, datasets, rows, fields, exports, Agent tools, and knowledge documents. A user who can view a campus-wide aggregate should not automatically receive access to identifiable trajectories. Particularly sensitive actions—single-student queries, academic associations, report exports, Agent requests, and knowledge-index updates—must create an auditable record of actor, time, purpose, parameters, and outcome.

Interfaces use HTTPS and authenticated service-to-service calls. Network zones and firewall rules restrict lateral access. Secrets are managed outside source code, database connections use least-privilege accounts, and import files are scanned and validated. Encryption at rest, backup protection, retention enforcement, vulnerability management, monitoring, and incident response should be incorporated according to institutional requirements.

The AI layer introduces additional controls. Prompt and conversation data should be minimized, protected, and subject to explicit retention rules. Retrieved documents must be approved for the requesting role. Tool parameters must be validated by the target service, and model output must never bypass authorization. The system should detect prompt-injection content in uploaded documents, return provenance, express uncertainty, and require human review for decisions that could materially affect a student. Ethical review, privacy impact assessment, and consultation with student representatives should precede any research or high-impact operational use.

8 Conclusion

This paper presents the design of an AI agent-based smart campus management platform that connects multisource acquisition, layered governance, Wi-Fi-derived trajectory reconstruction, spatiotemporal behavior analysis, anomalous-traffic warning, visualization, reporting, and RAG-grounded conversational analysis. Its central contribution is an integrated and governable technical route rather than a claim of experimental superiority. By separating transactional, analytical, application, and AI responsibilities and embedding authorization, desensitization, provenance, and audit controls, the design provides a practical basis for a campus analytics platform that can evolve with institutional needs. The next stage is controlled implementation and evaluation under formal governance, with particular attention to data quality, interpretability, security, privacy, and human oversight.

Generative AI statement

The author(s) declared that generative AI was not used in the creation of this manuscript.

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher’s note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Footnotes

Edited by: Xiaopeng Li, Guizhou University of Finance and Economics, China

Reviewed by: Lu Chen, Tianjin University of Technology, China

Qian Yin, Wuyi University, China