☆[Biligent] Overview of Bilient Data Agent Platform : Development Stage

Development Planning Document for a Data Agent Platform

A structured development framework for a multi-agent data interpretation platform

Overview
Development Planning Document for a Data Agent Platform is more than a simple functional requirements document. It is a comprehensive development standard for implementing a multi-agent data interpretation platform through 13 incremental development rounds, from R0 to R12.

Its central objective is to build a multi-domain, multi-user platform that can understand the structure of arbitrary data without relying on pre-existing documentation, negotiate and learn its meaning with users, and provide accurate answers together with the computational evidence and process behind them.

1. Document Summary

1.1 Core Development Objective

The platform is designed around the following workflow:

Data Upload → Data Profiling → Connectivity Graph Generation → Meaning Negotiation → Knowledge Accumulation → Query Interpretation → Calculation & Analysis → Evidence Presentation → User Feedback → Evaluation & Improvement → Self-Exploration & Algorithm Improvement

A key design principle is that answer accuracy should not depend solely on the capabilities of the LLM itself. Instead, the platform uses the LLM together with deterministic calculations and verification gates such as guard, critic, and query_slots. Outputs generated through LLM-based extraction, explanation, or candidate generation must pass deterministic validation before they can be used.

1.2 How the Platform Learns Data Meaning

Two of the most important concepts in the document are connectivity and conditional meaning structures.

Rather than storing meaning simply through column names or embedding vectors, the platform manages meaning as conditional rules:

Format Key + Accompanying Key/Value Conditions → Meaning

Therefore, the same key can have different meanings depending on the conditions surrounding the data. The system continuously updates these meanings through ongoing negotiation with users.

1.3 Division of Responsibilities Between Users and Agents

A central principle of the document is:

“Humans make the decisions; agents provide evidence and continuously improve.”

Agents may proactively propose meanings, knowledge, and algorithm candidates, but final confirmation is handled by humans. Knowledge follows a status hierarchy such as Needs Review → Approved → Confirmed, and the final transition to confirmed status is performed by a human.

1.4 Multi-Agent Architecture

The document clearly separates agents from software packages:

• Package: A code structure and reusable implementation unit
• Agent: A runtime role responsible for decision-making and collaboration

An entity qualifies as an agent only when all four conditions are satisfied:

1. It receives its own trigger.
2. It makes a decision among multiple alternatives.
3. It delivers its result in a contractual format.
4. When a failure occurs, it decides how to handle the situation, such as returning a partial result, placing the task on hold, or requesting user confirmation.

Based on these criteria, specialized agents such as A0, A1, A4, A5, A6, A7, and A8 are organized around the overall architecture.

1.5 Development Methodology

Development consists of 13 rounds, R0 through R12.

Each round is not merely a stage for adding code. Instead, it repeatedly follows a development cycle:

Planning → Review → Implementation Planning → Audit → Final Verification Gate → Implementation → Testing → Real-Environment Validation

Subsequent rounds are designed to extend the system without changing interfaces established in previous rounds. If a change becomes necessary, it is handled as a contract change. Existing tests remain in place as regression tests.

1.6 Data Processing and Calculation

To process large databases even on general-purpose PCs, raw data is not passed directly to the LLM. Instead, the system uses:

• Data profiles
• Samples
• SQL aggregation results

The platform also addresses large-scale processing through a two-stage scan, from sampling to full verification, together with parallel reads, progress reporting, and heartbeat mechanisms.

Calculations are managed through a staged structure called CalcPlan. Answer calculations, pre-calculations, and reproducibility calculations all use the same execution engine.

1.7 Learning and Continuous Improvement

The platform uses user questions and feedback as learning signals. In particular, it continuously improves its knowledge and answer paths using:

• User opinions
• Feedback on answers
• Questions that are repeatedly rejected
• Evaluation experiments
• Algorithm performance
• Data changes

In R11, eval_lab and A4 are used to measure quality before and after learning. In R12, A8 and codegen extend the platform toward new exploratory questions and improvements to algorithms and code.

1.8 Reliability and Quality Management

Answer accuracy is not defined simply by an LLM evaluation score.

Instead, domain-specific accuracy is calculated using a set of evaluation questions verified by humans as the denominator, with humans determining whether each answer passes.

Another distinctive feature is that a target accuracy value is not predetermined.

Testing is layered across unit, contract, independence, integration, end-to-end flow, invariant, wiring, regression, quality, non-functional, and real-environment testing.

2. Table of Contents

The document itself presents the following overall structure.

§1. Purpose and Scope

• 1-1. Purpose
• 1-2. Scope
• 1-3. Implementation Rules
• 1-4. Document Notation Rules

§2. Terminology

• Domain
• Connectivity Graph
• Node
• Value Role
• Format Signature / Format Rule
• Correction Rule
• Meaning Rule
• Knowledge Level
• Version / Source
• Dependency Reference
• Concept Ledger
• Storage Scope
• Node Filter
• Draft / Structural Modification
• Calculation Order (CalcPlan)
• Exclusion Record (Batch)
• Development Cycle / Round
• Package / Mid-Level Group / Top-Level Group
• Agent
• Coordinator
• Permission
• Slot
• Requirements and User Decision Rules

§3. Requirements

• 3-1. Objectives
• 3-2. Component Requirements
• Multi-Agent Collaboration
• Prior Information / Upload / Database Creation
• Data Analysis / Documentation / Connectivity Graph
• Meaning Negotiation / Learning / Evolution
• Calculation and Data Processing
• Question Answering and Evidence
• User Interface
• Progress Display
• Users / Domains / Permissions
• Personalization
• LLM Operation / Cost / Execution Environment
• External Search
• Answer Quality / Feedback Integration
• 3-3. Principles
• 3-4. Additional Requirements

The document defines highly granular requirements beginning with RQ-001 and links each requirement to its acceptance module and applicable development round.

§4. Module Structure

• 4-1. Two-Layer Structure and Unit Boundary Rules
• 4-2. Hierarchy
• 4-3. Agent Layer
• A0 Conversation Agent
• A1 Query & Calculation Planning Agent
• A4 Evaluation Agent
• A5 Research & Improvement Agent
• A6 Data Structure Analysis Agent
• A7 Meaning Negotiation Agent
• A8 Exploration Agent
• 4-4. Package Layer
• 4-5. Module Responsibilities
• 4-6. Dependency Rules
• 4-7. Top-, Mid-, and Small-Group Structure

Packages define code-structure boundaries, while agents define runtime decisions, triggers, and states. The package layer contains 33 package modules.

§5. Contracts

• Basic Contract Principles
• Request / Event Contracts
• Agent Collaboration Rules
• Asynchronous Execution and Locks
• Permission Matrix
• Contract Testing and Failure Handling

§6. User Decision Rules

• User Input and Opinions
• Structural Modification
• Meaning Decisions
• Knowledge Approval / Confirmation
• Calculation Rules and Calculation Order
• Data Inclusion / Exclusion
• Review / Reset
• User- and Context-Specific Application
• Confirmation Strength and Clarification
• Reanalysis Due to Data Changes

§7. Package Specifications

For each package, the document defines:

1. Purpose
2. Necessity and Use
3. Composition, Major Functions, and Performance
4. Detailed Requirements
5. Related Packages and Connections
6. Performance Requirements

Functional application rounds are also linked to PR-xx performance requirements.

The major package areas include:

ingest · profile · connectivity · understanding · meaning_structure · value_roles · knowledge · knowledge_policy · conversation · compute · grouping · algorithms · derived_data · qa · evidence_view · guard · critic · presentation · ui · observability · display_optimizer · user_ops · access · domain_lifecycle · llm_gateway · llm_policy · quality · quality_metrics · eval_lab · feedback · codegen · code_sandbox · pipeline_runner · and other foundational modules.

§8. Agent Specifications

• A0. Conversation Agent
• A1. Query & Calculation Agent
• A4. Evaluation Agent
• A5. Research & Improvement Agent
• A6. Data Structure Analysis Agent
• A7. Meaning Negotiation Agent
• A8. Exploration Agent
• Coordinator

For each agent, the document defines its purpose, triggers, inputs and outputs, decision scope, packages used, contracts, events, state, failure disposition, human gates, and performance requirements.

§9. Development Rounds

• 9-1. Round Development Principles
• 9-2. R0–R12 Round Sequence
• 9-3. Round Connections
• 9-4. Round Completion Conditions
• 9-5. Incremental Expansion / Modification Cycle / Cycle Count / Cycle Stages
• 9-6. Inputs to Round Documents
• 9-7. Items to Close in Round Implementation Plans

Each round is fundamentally an incremental extension that preserves the results of previous rounds while adding new functionality.

§10. Testing, Principle Gates, and Final Acceptance Scenarios

• 10-1. Layered Testing
• 10-2. Invariants
• 10-3. Wiring Inspection
• 10-4. Principle Gates
• 10-5. Final Acceptance Scenarios S1–S10

Testing is organized hierarchically from unit tests through real-environment tests. After R11, eval_lab experiments are also used to verify whether newly introduced changes cause regression.

§11. Slots

• 11-1. Integrated Management Agent Slot
• 11-2. web_search Slot

The two slots define interfaces only and do not have separate implementation rounds.

§12. Round-by-Round List

For each round from R0 to R12, the document organizes:

• Prerequisite rounds
• Implementation scope for the round
• Modules
• Functions
• Agents
• Coordinator
• Contract requests / events
• Round connections
• Related requirements
• User decision rules
• Permission matrix
• Input document types
• Principle gates
• Final acceptance scenarios
• Items to close in the implementation plan

3. Summary of the R0–R12 Development Flow

Round	Core Development Scope
R0	Basic architecture, contracts, independence/principle gates, UI/LLM Gateway, and the foundations for domains and permissions
R1	Minimum operational path — data upload, database creation, basic A0 queries, basic calculations and evidence
R2	Validation of methods for analyzing data formats and value roles
R3	Completion of the data-understanding foundation, including profiling, connectivity, data types, value roles, and meaning structures
R4	A7 meaning negotiation, user feedback, knowledge policy, and approval/confirmation framework
R5	Complex queries through A1, multi-step calculations, grouping, and pre-calculation
R6	Completion of A0, conversation reuse, clarification, and strengthened evidence and explanations
R7	A5 research/improvement loop and demand-driven learning
R8	Multi-user operation, permissions, personalization, LLM cost management, and data-export policies
R9	Domain initialization, export/import, and transfer of confirmed knowledge
R10	Completion of user presentation through evidence views, display optimization, graphs, tables, and traces
R11	A4 evaluation, quality measurement, feedback learning, and algorithm improvement evaluation
R12	A8 self-exploration, codegen, code_sandbox, algorithm adoption, and final acceptance

For example, R7 adds a research and improvement loop centered on A5 and pipeline_runner. R12 extends this through A8 and codegen, connecting exploratory questions with algorithm and code improvements.

4. Structural Characteristics of the Document

Viewed as a whole, DevProcess200 defines both “how to build a data agent” and “how to validate that data agent” within a single development standard.

The five characteristics below are particularly important:

1. Data-centric — Designed to generalize to arbitrary data rather than a specific sample dataset.
2. Multi-agent collaboration-centric — A0–A8 are separated according to their respective roles.
3. Human-agent collaboration-centric — Agents make proposals, while humans confirm important decisions.
4. Deterministic verification-centric — Free-form LLM output is not directly used as an operational result.
5. Round- and test-centric — R0–R12 provide incremental development with continuous regression and quality evaluation