Purpose and Scope : Biligent#1

Overview of Biligent

1. Purpose and Scope

1-1. Purpose

Develop a new multi-domain, multi-user data interpretation platform for arbitrary systems for which only data is provided without explanatory documentation. Multiple agents collaborate to analyze the data structure, learn its meaning through interaction and feedback with users, and provide accurate answers to user questions together with supporting evidence. This document defines the requirements (§3), module structure, contracts, specifications, rounds, and tests for the platform.

1-2. Scope

• All modules are newly implemented. Development is divided into one-way incremental rounds R0–R12 (§9).
• Excluded from the implementation scope:
  1. Questionnaire-based interaction (presenting, uploading, partially answering, adding questions, or questionnaire buttons) — semantic input is handled by the node opinion input, while calculation-rule input is handled by the calculation-rule input screen (§6 UR-01).
  2. Comprehensive or shared methods for knowledge inference across domains.
  3. Functionality for combining multiple source tables within a single domain into a unified semantic model for analysis.
  4. A statistical post-processing layer.
  5. Preliminary investigation of sibling projects (no inspection).
  6. Dedicated code/SQL interpretation (translating conditional statements into business rules) — uploaded code and SQL are handled through the same path as other user documents (§7 user_input, accept_prior_info).
• Handled through other configurations rather than separate functionality:
  1. A separate development-only screen — development screens are also treated as user screens (ui).
  2. A no-cost LLM dedicated to the development stage — handled through the backend configuration of llm_gateway.
  3. Separation of investigation and approval permissions — they are not separated (§5-5 permission table).
  4. A dedicated prediction/diagnosis agent — handled through algorithms in algorithms and question types in A1.
  5. Maturation through multiple repeated cycles — handled as round-based iteration rather than as a product feature.
• Two slots (the integrated management agent and web_search) define interfaces only and have no implementation round.

1-3. Implementation Response Rules

#	Target	Rule
1	Answer accuracy	For each domain, a set of evaluation questions verified by humans is used as the denominator, and human pass confirmation is defined as the judgment criterion. quality_metrics calculates and reports the results by domain (no target value — PR-05).
2	Independence from LLM performance	Only deterministic calculations are used for values. All LLM outputs (slot extraction, semantic candidates, explanatory text, and code generation) pass deterministic validation through guard, query_slots, and critic. Backend-specific evaluation experiments (A4) verify the quality floor for the validation-gate pass rate.
3	Algorithm improvement and code generation	Combinations from the algorithms list are tried first. New code is adopted only after execution in code_sandbox, deterministic result validation, successful evaluation experiments, and human approval (codegen.adopt). Code is not used for operational answers before adoption. The isolation mechanism is specified by operating system in the implementation plan.
4	General-purpose PCs and large databases	Raw data is not provided to the LLM; only profiles, samples, and SQL aggregations are provided. A two-stage scan is used: sample analysis followed by full-data verification. Read operations are parallelized (parallel), and loading/analysis progress events expose waiting time to the user.
5	Progress	Display a percentage based on the number of stages, an elapsed-time estimate within each stage, and a heartbeat (at a period within PR-01). The screen must indicate that the estimate is an approximation (observability.progress).
6	Immediate verification	Within the time budget (PR-03), perform only deterministic checks and run LLM verification asynchronously. If the budget is exceeded, the default path is to retain only safety measures and proceed to the next question.
7	Context-specific semantic structuring	Store meaning as conditional rules in the form “format key + accompanying key/value conditions → meaning,” rather than embedding it in vectors. If rules overlap, A7 asks the user for confirmation.
8	Concurrent access	Long-running tasks are executed asynchronously using task-request records and a single execution lock, as in A4 and A5 (§5-4). Screen requests are primarily read-oriented. The number of concurrent users is defined by PR-19.
9	User- and context-specific judgments	The default is a common definition. Only when differences are confirmed through feedback are definitions separated by the applicable scope (user/context) in knowledge_policy.
10	Agent self-generated questions	A8 generates questions only from the connection-graph structure and demand records for unanswered questions, with an upper limit on the number presented per round (a policy constant — if 0, no questions are presented).
11	Silent functional degradation	Detect degradation through regression tests from previous rounds (§9-4), quality_metrics reports, and repeated rejection signals. The domain administrator identifies issues through quality reports.

1-4. Document Notation Rules

• Section numbers refer only to sections within this document (§7 access means the access specification in §7). The sole exception is the closing marker in §9-7, which is added when this document is updated after a round has been completed.
• Requirements are denoted as RQ-nnn (§3), user decision rules as UR-nn (§6), performance requirements as PR-nn (§7 and §8), items to be closed in round implementation plans as CL-nn (§9-7), and final acceptance scenarios as S1–S10 (§10-5).
• Fields whose values have not yet been determined are written as “TBD — to be finalized in the review report” (for requirement-level values) or “TBD — to be finalized in the implementation plan” (for values that depend on the implementation approach). The review report or implementation plan for the relevant round must fill in the field for the document to be considered complete. The closing round is determined by the round designation of the function row or item containing the field. If the field is outside a function row/item, use the round designation of the function or item to which the field refers. For fields not belonging to a module or agent, use the round in which the value is first specified. If the applicable round cannot otherwise be determined, use the first round of the relevant module or agent. If multiple round designations result, use the round in which the operation affected by that value is introduced.
• The round designation Rn indicates the round in which the corresponding function, connection, requirement, or item is introduced. If an item spans two or more rounds, specify in parentheses what is included in each round.