Industrial Agent · Digital Staff Standard System (v2.0 Merged Edition)

This document is the sole definition and standard basis for the BossAgents platform regarding "Industry / Position / Digital Staff / Agent" and its governance foundation (object model, rule engine, relationship engine, multi-agent collaboration, 5-end collaboration).

All new, modified, and reviewed code, configurations, and documents must comply with this document.

For the corresponding implementation architecture, refer to docs/06_DIGITAL_STAFF_UNIFICATION.md (defining the source consolidation solution).

0. Standard Framework and the Overpass of Two Perspectives

The platform has two complementary perspectives that converge at the "Digital Staff" layer:

• Business-side four layers (Who does what for whom): Industry → Position → Digital Staff → Agent.

Defines "who is served, what is done, who does it, how it's done," mapping organization and business.

• Technology/Governance-side five layers (How to ensure reliability): Agent Foundation → Object Model → Rule/Relationship Engine → Digital Staff → Multi-Agent Collaboration, traversed by "5-End Collaboration."

Defines "how agent capabilities are composed, how behavior is constrained, how collaboration is conducted," serving as the engineering and governance foundation.

In short: The business-side four layers describe "what a Digital Staff is," the technology/governance-side five layers describe "how a Digital Staff works reliably." The Digital Staff is the convergence and encapsulation layer of both.

I. Business-side Four-Layer Concept Definitions (Industry / Position / Digital Staff / Agent)

For detailed definitions, refer to the approved content in v1.0. Here, a simplified version aligned with the governance side and code implementation points is provided.

First Layer: Industry

A collection of units engaged in economic activities of the same nature (GB/T 4754 homogeneity principle). Positioning: Top-level business domain, defining "who is served."

• Code Implementation Point: Knowledge base industry codes (e.g., phos_chem for phosphate chemical, baijiu for baijiu); The event_subscriptions section in local.yaml is already linked to industry: phos_chem. To be added: The positions section does not explicitly mark industry affiliation.

Layer 2: Position / Role

A unit of responsibility established by the organization to accomplish tasks (positions are created based on needs, with clear duties, organizational attributes, and relative stability). Positioning: The bridge from industry to work, defining "what to do."

• Code location: The `positions:` section in local.yaml (16 positions, including `members:` mapping to digital employee IDs), backend `/api/digital-staff/positions` (server.js:4895), and frontend rendering in the "Position System" tab of DigitalStaff.vue.

Layer 3: Digital Employee

A virtual workforce possessing the closed-loop capability of "perception—planning—action—learning," representing a combination of "digital-intelligent technology + process encapsulation + organizational role." Positioning: The digital bearer of a position, defining "who is doing it."

• Code location: The `staff:` section in local.yaml (the sole editable source, currently 77 entries) → mirrored to the `digital_staff` table in server/data/rule_engine.db via `syncStaffToDb` (runtime mirror, not manually editable). `tier: base/domain/sub` distinguishes basic verb / domain / sub-capability.
• Recognition Criteria (detailed in governance side, Layer 4): Must possess position identity, position mapping, permission boundaries, result delivery, governability, and continuous evolution (see §IV-1 for details).

Layer 4: AI Agent

The minimal capability unit with autonomous perception, memory, decision-making, interaction, and execution abilities (GB/Z 185—2026). Positioning: The technical core driving digital employees, defining "how to do it."

• Code location: server/boss-scheduler/workers/*.js (each file exports a `run(staff, ctx, intent, parameters)`, representing an independently callable AI agent capability unit).
• One-to-many evidence: chip-worker.js is shared by DS-CHIP-001~007 (type: capability_mode); goai-agent-worker.js is shared by GOAI-SCHED/PROC/EQUIP (type: role_prompt); procurement-chain-worker.js is shared by DS-*CHAIN-001 (type: workflow_step).

II. Five-layer technical/governance standard system

Core principles (all inherit the national standard framework):

1. Object model-driven: PLM is the single source of truth; without an object model, rules/relationships/collaboration lack a common language.
2. Layered decoupling: Each layer is independently defined, standardized, and interfaced; layers communicate via standardized protocols and can evolve independently.
3. Standards first: Development not adhering to standards will not be listed; deployments not meeting standards will not be approved.
4. Composable and extensible: The agent is the smallest unit, supporting one-to-many / many-to-one / many-to-many combinations.
5. Secure, trustworthy, and controllable: Decisions must be explainable, auditable, and reversible; any agent must support human takeover and emergency stop.

First layer: Agent foundation standards (eight functional modules + classification and grading)

Based on GB/Z 195-2026 "Artificial Intelligence - Industrial Agent Reference Architecture" + "Industrial Agents - Part 1: General Requirements", each industrial agent must possess:

| Functional Module | Standard Requirements | Code Implementation in This Project (Current Status/Gaps) |

|-------------------|-----------------------|----------------------------------------------------------|

| Perception | Multi-modal input, environmental perception | workers perceive via ctx.db read-only SELECT + parameters input; multi-modal (image/voice) gap |

| Memory | Short-term/long-term memory | ctx.staffLog + rule_engine.db for audit; long-term memory (knowledge graph) gap |

| Reasoning | Symbolic + Statistical Reasoning | Four-verb worker field-level/null-value reasoning; LLM probabilistic reasoning via llm:true staff |

| Planning | Task Decomposition & Path Planning | pipeline: fields (DS-BIZ-001 / DS-PLM-BRAIN-001) + loop: iteration; chained collaboration.onComplete |

| Decision-Making | Autonomous Decision-Making, Explainable | requestConfirmation for high-risk escalation to human; decision explanation pending |

| Execution | Tool/API Invocation | mtclaw_high_frequency_actions + DB/service calls within worker |

| Communication | Compliant with GB/Z 185 Interconnection | Gap: staff-router.js does not consume type field; inter-agent communication protocol not standardized |

| Evolution | Learning & Optimization from Feedback | skeleton staff implemented:'skeleton' for honesty + subsequent filling; automatic evolution gap |

Classification & Grading (per 'Industrial Agent Classification and Grading Evaluation Guide'): Foundational Level L1 / Assistant Level L2 / Autonomous Level L3 / Self-Governing Level L4.

Identity Code: Each agent must have a unique identity code → This project uses DS-XXX staff ID + worker filename, already satisfied; recommendation to add independent worker-level identity code.

Standard Document List: GB/Z 195-2026, General Requirements for Industrial Agents, GB/Z 185.1～185.7—2026, IEEE P3945.

Second Layer: Object Model Standard (PLM Unified Semantic Base)

The object model is the foundation for all upper-layer capabilities—without it, rules have no operands, relationships have no nodes, and collaboration lacks a common language.

Core Object Types (referencing AAS Meta-Model):

• Physical assets: equipment, production lines, products, materials
• Logical assets: BOM, drawings, processes, documents
• Process objects: workflows, approval flows, production takt
• Role objects: positions, permissions, responsibilities
• Data objects: parameters, metrics, logs, events

Five types of object model views: geometric / physical / behavioral (state machine/sequence) / rule / data.

Lifecycle: modeling → construction (machine-readable) → testing (completeness/consistency) → deployment (registered to model library + unique identifier) → evolution (version management).

• This project's code implementation points (strongly relevant, not pie-in-the-sky):
• server/utils/SCSAI-tools.js: SCSAI PLM 469 industrial object model base (equipment/product/BOM/process/project, etc.), the actual carrier of this layer's "object model library."
• server/data/kb/.db: Industry knowledge base (kb_docs / industry_bom, etc.), object instance storage.
• server/data/sccapp_process_data.db: Process objects (pps_* 7 core tables).
• The item_types: field in local.yaml (e.g., ECR for DS-ECR-001, CASC211_JG_Q_CONTROL_CARD for DS-QCC-001) represents the mapping annotation of "role/logical objects" onto employees.

Standard Document List: IDTA-01001 AAS Metamodel, GB/T 45616.2-2025 Digital Twin Reference Architecture, GB/T 45626-2025 General Requirements for Equipment Digital Twin Systems.

Layer 3: Rule Engine and Relationship Engine Standards (Decision Base)

The rule engine defines 'what can be done and what cannot be done' (constraints and boundaries), while the relationship engine defines 'who is related to whom and how' (context and semantics). Together, they form the decision base for the agent.

Rule Engine Standards: Unified Rule Description Language (IF-THEN / Decision Tables / Decision Trees), priority and conflict resolution, lifecycle management, deterministic guarantees, auditability, human priority (can be overridden).

• Project code location: The sciot_rules_v2 / sciot_templates / prompt_templates tables in server/data/rule_engine.db (actual rule storage); server/boss-scheduler/lib/consistency-check.js performs rule/template consistency checks; server/services/document-rule-template-manager.js manages rule templates.

Relationship Engine Standard: Relationship metamodel (entity-relationship-entity triples), relationship types (inheritance/composition/dependency/constraint/communication/collaboration), relationship reasoning, visualization, runtime dynamic binding.

• Project code location: server/boss-scheduler/lib/consistency-check.js (consistency/relationship validation), positions.members + collaboration.onComplete + event_subscriptions in local.yaml (declaration of relationship network), tasks/task-force-store.js (L3/L4 collaboration lift-off library).

Rule + Relationship Collaboration: Rules provide deterministic guarantees, relationships provide contextual awareness, ensuring safe and reasonable decision-making in industrial environments.

Fourth Layer: Digital Employee Standard (encapsulation of job roles and business delivery).

1. Digital Employee Qualification Criteria (must meet these to be called a digital employee):

| Criterion | Requirement | Project Implementation |

|--------|------|-----------|

| Job Identity | Job title/code/responsibilities | title / description fields |

| Job Mapping | Correspondence with industry-job system | positions.members reference |

| Permission Boundary | Operation/data permissions | mtclaw_high_frequency_actions + item_types |

| Results Delivery | Quantifiable KPIs | Gap: KPI fields not yet defined |

| Governability | Logging/Auditing/Assessment | ctx.staffLog + rule_engine.db audit |

| Continuous Evolution | Data Feedback Optimization | Skeleton Honestification + Subsequent Loading |

2. Digital Employee Capability Levels: L1 Basic Automation / L2 Collaborative Assistance / L3 Conditional Autonomy / L4 High Autonomy in Specific Domains / L5 Full Autonomy in All Scenarios.

3. Digital Employee ↔ Position Mapping Standard: One employee can undertake multiple positions, one position can correspond to multiple employees. Mapping must be recorded in the PLM object model (i.e., positions.members).

Standard Document List: Industrial Agent Classification and Grading Evaluation Guide, T/SAIAS 055-2026 Agent Capability Grading and Evaluation Requirements.

Fifth Layer: Multi-Agent Collaboration Standards (Cross-Agent Communication and Collaboration)

1. Communication Protocols: GB/Z 185.6 Agent Interaction, IEEE P3945.1 Interoperability, A2A Protocol, MACP Manufacturing Multi-Agent Protocol.

2. Swarm Intelligence: IEEE P3961 Dynamic Networking / Task Decomposition / Collaborative Decision-Making / Fault-Tolerant Control.

3. Agent-Tool-Data Access: IEEE P3945.2 Unified Data Format / Interface Specification / Synchronous Asynchronous / Quality Requirements.

• Project Code Implementation: collaboration.onComplete (DS-BIZ-001→DS-REPORT-001, DS-STOCK-001→DS-PROC-001) is a lightweight implementation of "Task Decomposition + Collaboration"; tasks/task-force-*.js is the real foundation for L3/L4 swarm collaboration (approval/conflict detection/timeout reminders). Standardizing agent-to-agent communication protocols (A2A/MACP) is pending.

III. 5-End Collaboration Standards (Cross-cutting Layer)

| End | Definition | Core Responsibilities | Corresponds to Platform |

|----|------|----------|-----------|

| Cloud | Cloud Data Center | Global Coordination, Large Models, Knowledge Base | SCSAI PLM Cloud + Knowledge Base Sub-repositories |

| Edge | Edge Node | Real-time Inference, Preprocessing | ✅ server/edge/edge-node-manager.js (Node Registration/Heartbeat/Dispatch/Load Balancing) |

| Device | Terminal Device | Ubiquitous Sensing, Collection | Mini Program / Equipment Ledger (DS-EQUIP-001) |

| Network | Network Infrastructure | Computing Power Interconnection, Orchestration | ✅ server/network/network-manager.js (Link/Routing/QoS/Retransmission) |

| Intelligence | Agent System | Perception-Decision-Action Closed Loop | All of This Standard System (workers + engines) |

Five-End Collaboration Requirements: Integration of Sensing-Computing-Control-Intelligence, Device-Cloud Collaboration, Edge-Cloud Collaboration, Network Interconnection, Consistency Assurance (consistent data models/semantics/states across five ends).

Integration with Object Model: The same object model maintains semantic consistency across cloud, edge, and device—the 469 object meta-model in SCSAI-tools.js is the foundational common language for the five ends.

IV. Standard Implementation Path (Five Phases, Aligned with National Framework)

V. Standards Compliance Verification (Required before release)

VI. Overall Diagram of Standard System Relationships

        ┌─────────────────────────────────────────┐
        │  治理侧第五层：多智能体协同              │  GB/Z 185.6 / IEEE P3945.1 / A2A
        └───────────────────┬─────────────────────┘
                            │ 协同基于
        ┌───────────────────▼─────────────────────┐
        │  治理侧第四层：Digital Staff（立交桥层）      │  岗位映射·权限·结果交付
        └─────────┬─────────────────────┬──────────┘
   业务侧四层交汇 │                     │ 由智能体驱动
        ┌─────────▼──────────┐   ┌──────▼──────────────────────┐
        │ 业务侧：行业→岗位  │   │ 治理侧第三层：规则+关系引擎  │
        │ （local.yaml       │   │ 确定性保障·上下文感知·决策  │
        │  positions 段）     │   └──────────┬───────────────────┘
        └────────────────────┘              │ 操作对象来自
                                  ┌─────────▼───────────────────┐
                                  │ 治理侧第二层：对象模型       │
                                  │ PLM统一语义底座·AAS元模型    │
                                  └─────────┬───────────────────┘
                                            │ 能力定义依据
                                  ┌─────────▼───────────────────┐
                                  │ 治理侧第一层：智能体基础     │
                                  │ GB/Z 195-2026 八大功能模块   │
                                  └─────────────────────────────┘

        ┌─────────────────────────────────────────────────────┐
        │  贯穿层：5端协同（云·边·端·网·智 一体化）            │
        └─────────────────────────────────────────────────────┘

六-B、核心落地机制：智能体 / 数字员工作为 PLM 对象注册（Aras 语义底座）

本平台做工业智能体最得天独厚的优势：PLM 源自 Aras Innovator（Gartner 魔力象限常年 Top 2 的 PLM），对象模型天然基于 ItemType / RelationshipType / AML 语义。别人要从零搭对象模型底座，我们直接站在 Aras 的语义底座上——智能体和数字员工不需要"另建一套注册机制"，它们就是两类标准的 PLM 对象。

1. Current Status of the PLM Object Model Foundation (Implemented, Not a Castle in the Air)

The platform object layer server/utils/SCSAI-tools.js is already a complete mapping of Aras Innovator semantics, with data stored in server/data/rule_engine.db:

| Aras Concept | This Project's Table | Meaning |

|-----------|----------|------|

| ItemType | sciot_item_types (is_relationship / is_versionable / implementation_type) | Object class, supporting version management and lifecycle |

| RelationshipType | sciot_relationships (source_item_type — name(behavior) — related_item_type) | Entity-Relationship-Entity triple, precisely the metamodel required by the governance side's third-layer relationship engine |

| Property | sciot_properties | Object properties (including is_required / is_keyed / data_source) |

| AML / Template | sciot_templates (aml_template / generation_rules) | Aras AML generation and field rules |

Examples of registered object classes: PART (Component/Material), DOCUMENT, CAD, PRODUCT, PROJECT, ECR, ECO, CHANGE, WBS ELEMENT, etc. — Agents/Digital Workers will be added as new ItemTypes alongside these, interconnected via standard RelationshipTypes.

2. PLM Object Registration Standard for Agents / Digital Employees

Add two new ItemTypes (standard objects, not bypass configurations):

| ItemType | Name | Key Properties | Version/Lifecycle |

|----------|------|----------------------|---------------|

| AGENT | Agent | agent_id (unique identifier/keyed), name, capability (verb), worker (implementation file), level (L1~L4), memory_type, comms_protocol (GB/Z 185.6/A2A) | Versionable |

| DIGITAL_EMPLOYEE | Digital Employee | staff_id (DS-XXX/keyed), title, position_ref (position), industry, tier, kpi_def, enabled | Versionable |

Registration takes effect immediately: AGENT and DIGITAL_EMPLOYEE are registered into PLM via the smartCreateItemType / AML channel of SCSAI-tools.js, residing in the same database and source as existing PART/BOM/ECR, inherently satisfying the "object model-driven" principle (cannot register without an object model; registration makes them part of the single source of truth).

#### 2.1 Code Implementation Entry Point (Already Implemented, Can Be Re-run)

| File | Purpose | Implementation Point |

|------|------|------|

| server/boss-scheduler/registerAgentObjects.js | Registration script (idempotent, checks for duplicates before writing) | Dual-track: Must land in local rule_engine.db; if the remote SCSAI server is reachable, pushes via the SCSAI-tools AML channel; if unreachable, degrades to local-only storage |

| rule_engine.db → sciot_item_types | AGENT(id=3) and DIGITAL_EMPLOYEE(id=4) ItemTypes + standard attributes written | Local authoritative cache for object model lineage |

| rule_engine.db → sciot_relationships | 7 predefined R_* RelationshipTypes written (R_AGENT_ENCAPSULATES/R_AGENT_CAPABILITY/R_STAFF_POSITION/R_STAFF_INDUSTRY/R_AGENT_OPERATES_ON/R_AGENT_CALLS/R_STAFF_GOVERNED_BY) | Relationship engine meta-model landing point |

| rule_engine.db → agent_registry | New registry table created, 77 digital employees + 7 base agent instance mappings landed (including remote_status='pending_remote') | Local PLM object instance mapping, foundation for real business closed-loop graph queries |

Execution result (actual test): node server/boss-scheduler/registerAgentObjects.js → ItemType reused 2, Relationship created 7, registry entries 84 (77 DE + 7 AGENT), automatic downgrade when remote PLM is unreachable, never blocks locally.

Remote push (Item 3, environment-dependent, execute after credentials are ready):

• Prerequisite: Configure SCSAI_SERVER / SCSAI_DATABASE / SCSAI_USERNAME / SCSAI_PASSWORD in .env (pointing to Aras PLM server).
• Execution: Re-run node server/boss-scheduler/registerAgentObjects.js. The script first sends an ItemType get probe to confirm connectivity, then uses SCSAI-tools.smartCreateItemType to actually push the AGENT / DIGITAL_EMPLOYEE two object types to PLM (built-in duplicate checking allows repeated runs).
• Current status: Remote credentials are not configured; 84 records are only stored locally in agent_registry (remote_status='pending_remote'). The script is designed to honestly print and skip when credentials are unconfigured/unreachable, never faking reachability, adhering to the "standards first, zero fake successes" principle.
• ⚠️ No fake pushes: The current environment lacks Aras server credentials. Item 3 is a one-click execution action for after you provide credentials, not a completed item.

Attribute naming alignment: Standard Section 2 attribute names (agent_id/staff_id) are semantic names; code uses database column names like agent_code/staff_code when persisting. The frontend/routes consume agent_registry + digital_staff.config as the single source of truth to avoid dual-write drift.

3. Relationship Establishment Standards (How to connect them for real interoperability)

Agents/Digital Employees and business objects, as well as among themselves, establish relationships via standard Aras RelationshipTypes. Predefined relationships (semantically aligned with Aras + governance-side third-layer relationship types: inheritance/composition/dependency/constraint/communication/collaboration):

| RelationshipType | Source → Target | Semantics (Standard Basis) | Business Meaning |

|------------------|-----------|------------------|----------|

| R_AGENT_CAPABILITY | AGENT → AGENT (or DIGITAL_EMPLOYEE) | Composition/Collaboration | An employee is driven by multiple agents (many-to-one) |

| R_AGENT_ENCAPSULATES | DIGITAL_EMPLOYEE → AGENT | Composition | A single agent encapsulates multiple employees (one-to-many) |

| R_STAFF_POSITION | DIGITAL_EMPLOYEE → POSITION | Dependency/Mapping | An employee assumes a certain position (position → employee bearer) |

| R_STAFF_INDUSTRY | DIGITAL_EMPLOYEE → INDUSTRY | Dependency/Affiliation | An employee serves a certain industry (industry → position scenario) |

| R_AGENT_OPERATES_ON | AGENT → PART/BOM/ECR/... | Dependency/Operand | The specific business object operated by the agent (object model-driven) |

| R_AGENT_CALLS | AGENT → AGENT | Communication/Collaboration | Multi-agent collaborative call chain (A2A/MACP) |

| R_STAFF_GOVERNED_BY | DIGITAL_EMPLOYEE → RULE | Constraint | An employee is constrained by a certain rule (rule engine boundary) |

Relationships are capabilities: Because relationships are first-class citizens in PLM (stored in sciot_relationships), agents "can connect and interact" not by hard-coded scripts pulling colleagues, but by querying the relationship graph—"finding all AGENTS where R_AGENT_CALLS points to me" discovers collaborators, "finding AGENTS where R_AGENT_OPERATES_ON points to a PART" discovers employees capable of handling that material. This is the collaborative capability directly enabled by the Aras relationship engine.

4. Closed Loop for Actual Business Operations (Standard → Implementation)

自然语言/事件
   │  （如 "采集磷化工知识" / ncr.created 事件）
   ▼
PLM 查关系：DIGITAL_EMPLOYEE ─[R_STAFF_POSITION]→ POS-OPERATOR ─[R_STAFF_INDUSTRY]→ 磷化工
   │  定位到具体员工 DS-KBPIPE-001
   ▼
执行：AGENT(worker=chip-worker 等) ─[R_AGENT_OPERATES_ON]→ PART/BOM
   │  按 sciot_rules_v2 规则约束 + sciot_relationships 上下文
   ▼
结果回写 PLM：Create/更新 ItemType 实例 + 写 sciot_creation_history（可审计）
   │  + staffLog（可治理）
   ▼
闭环完成：对象模型驱动 → 规则约束 → 关系感知 → 多智能体协同 → 结果落库

这正是标准要求的"对象模型驱动、规则引擎约束、关系引擎感知、多智能体协同"在 Aras 底座上的真实落地，不是补丁。

Code implementation support: After registerAgentObjects.js writes the agent_registry (77 DE + 7 AGENT) and the 7 types of R_* relationships into the rule_engine.db, the aforementioned closed loop of "query relationship graph to locate employee → execute → write back audit" can directly consume agent_registry + sciot_relationships as the query foundation. The front-end "Position System" tab can also consume data from agent_registry via R_STAFF_POSITION / R_STAFF_INDUSTRY relationships, rather than being read-only from local.yaml. When the remote Aras server is reachable, push the ItemType/Relationship with the same name via the SCSAI-tools AML channel, enabling local and remote to share the same semantic set without conflict.

5. Integration with Existing Definitions (No Duplication, No Conflict)

• This mechanism replaces the "to be filled" mentioned in v2.0 for staff-router.js, which did not consume the type field. It is now changed to: Type information (capability_mode / role_prompt / workflow_step) is registered as the capability attribute of the AGENT + the R_AGENT_ENCAPSULATES relationship. The routing layer now queries PLM relationships instead of reading YAML fields.
• This mechanism strengthens the "position → employee mapping" in the business-side four-layer structure: positions.members is replaced by the PLM R_STAFF_POSITION relationship, and the front-end "Position System" tab directly consumes the PLM relationship graph.
• Agent Identity Code: The AGENT's agent_id serves as the unique identity code (as required by GB/Z 185), forming a dual-layer identification of "employee-agent" alongside the DS-XXX employee ID.

VII. References and Basis

• Business Side: GB/T 4754 "Industrial Classification for National Economic Activities"; GB/Z 185—2026 "Artificial Intelligence — Agent Interconnection"
• Governance Side: GB/Z 195-2026 "Artificial Intelligence — Industrial Agent Reference Architecture", "Industrial Agent — Part 1: General Requirements", "Artificial Intelligence — Industrial Agent Classification and Grading Assessment Guide", GB/Z 185.1～185.7—2026, IEEE P3945/P3961
• Object Model: IDTA-01001 AAS Metamodel, GB/T 45616.2-2025, GB/T 45626-2025
• PLM Foundation: Aras Innovator (Gartner PLM Magic Quadrant Top 2) ItemType / RelationshipType / AML Semantics; Project mapping see server/utils/SCSAI-tools.js (sciot_item_types / sciot_relationships / sciot_properties / sciot_templates)
• Project Support: docs/06_DIGITAL_STAFF_UNIFICATION.md, server/boss-scheduler/profiles/local.yaml, server/boss-scheduler/workers/, server/utils/SCSAI-tools.js, server/data/rule_engine.db, server/boss-scheduler/lib/consistency-check.js