Summary of preliminary data acquired by the agent during RAG.
Contains lightweight identifiers for each kind of preliminary data that was
loaded into the agent's local context before producing its output. Only the
kinds specified by the Kind type parameter are present.
Number of items completed.
Tracks how many items have been successfully processed so far in the current operation. This value increments as each item is completed, providing real-time progress indication.
The ratio of completed to total gives the completion percentage:
progress = (completed / total) * 100
Corrected schema definition based on review feedback, or null if no changes are needed.
When not null, carries exactly one corrected model for the reviewed target table (modelName) so that the AI output stays within the LLM's maximum output token limit. If the review determines that additional child tables are required, they are declared in AutoBeDatabaseSchemaDefinition.newDesigns as lightweight name + description pairs and will be generated by subsequent pipeline calls.
If null, the original model remains unchanged in the schema. If not null,
the corrected model replaces the original, and any newDesigns entries are
fed back into the schema generation pipeline.
Timestamp when the event was created.
ISO 8601 formatted date-time string indicating when this event was emitted by the system. This timestamp is crucial for event ordering, performance analysis, and debugging the agent workflow execution timeline.
Format: "YYYY-MM-DDTHH:mm:ss.sssZ" (e.g., "2024-01-15T14:30:45.123Z")
A unique identifier for the event.
Function calling trial statistics for the operation.
Records the complete trial history of function calling attempts, tracking total executions, successful completions, consent requests, validation failures, and invalid JSON responses. These metrics reveal the reliability and quality of AI agent autonomous operation with tool usage.
Trial statistics are critical for identifying operations where agents struggle with tool interfaces, generate invalid outputs, or require multiple correction attempts through self-healing spiral loops. High failure rates indicate opportunities for system prompt optimization or tool interface improvements.
Name of the specific table model being reviewed.
Identifies the exact table that was reviewed within the namespace, enabling precise tracking of which tables have been validated and which modifications (if any) were applied.
Namespace of the business domain containing the reviewed table.
Identifies which business domain (schema file) this reviewed table belongs to, enabling proper organization and aggregation of review results by domain.
Strategic database design plan that guided the target table and child table creation.
Contains the original planning document that outlines the database architecture strategy for the target table and any child tables, including structure, relationships, normalization approach (with 1NF child table decomposition), and business requirement mapping. This plan serves as the blueprint for validating the implemented models.
Planning Components:
Example:
"Database Design Strategy for 'shopping_orders':
Business Requirements:
- Track customer purchase orders with complete order information
- Support order status workflow and payment tracking
- Enable historical order analysis and reporting
1NF Decomposition:
- shopping_order_items: Separate table for line items (repeating group)
- shopping_order_payments: Separate table for payment records
Design Approach:
- Normalize order data to 3NF for data integrity
- Implement temporal fields for audit trail
- Create composite indexes for customer and date queries
- Foreign keys to shopping_customers and shopping_payments"
Comprehensive review analysis of the target table and its child table models.
Contains the AI agent's detailed evaluation of the target table and any child tables, including validation of normalization compliance (with emphasis on 1NF enforcement through child table decomposition), relationship integrity, index optimization, and business requirement alignment. The review identifies potential issues and confirms adherence to best practices.
Review Dimensions:
Example:
"After reviewing the target table 'shopping_orders' and its child
tables 'shopping_order_items' and 'shopping_order_payments':
1. Target table properly implements UUID primary key
2. Child tables correctly decompose order items and payments (1NF)
3. Foreign key relationships correctly reference existing models
4. Composite indexes optimize for common query patterns
5. Temporal fields (created_at, updated_at, deleted_at) are present
All tables follow best practices and are ready for implementation."
Iteration number of the requirements analysis this review was performed for.
Indicates which version of the requirements analysis this schema review reflects. This step number ensures that the database review and modifications are aligned with the current requirements and helps track the evolution of database architecture as business requirements change.
The step value enables proper synchronization between database review activities and the underlying requirements, ensuring that the schema structure remains relevant to the current project scope and business objectives.
Detailed token usage metrics for the operation.
Contains comprehensive token consumption data including total usage, input token breakdown with cache hit rates, and output token categorization by generation type (reasoning, predictions). This component-level tracking enables precise cost analysis and identification of operations that benefit most from prompt caching or require optimization.
Token usage directly translates to operational costs, making this metric essential for understanding the financial implications of different operation types and guiding resource allocation decisions.
Total number of items to process.
Represents the complete count of operations, files, endpoints, or other entities that need to be processed in the current workflow step. This value is typically determined at the beginning of an operation and remains constant throughout the process.
Used together with the completed field to calculate progress percentage
and estimate time to completion.
Unique identifier for the event type.
A literal string that discriminates between different event types in the AutoBE system. This field enables TypeScript's discriminated union feature, allowing type-safe event handling through switch statements or conditional checks.
Examples: "analyzeWrite", "databaseSchema", "interfaceOperation", "testScenario"
Event fired when the Database agent reviews and validates a single target table model during the database schema design process.
The review validates the target table against best practices, business requirements, and technical constraints — covering normalization compliance, relationship integrity, indexing strategies, naming conventions, and temporal field handling.
Based on the findings the agent provides a corrected model in content (with optional AutoBeDatabaseSchemaDefinition.newDesigns for newly required child tables), or null if the model passes validation.
Author
Samchon