What the data for this category looks like
This category’s data originates from the in-orbit telemetry database of the aerospace measurement and control center, ground equipment operation ledger systems, and the national defense and military industry supporting cost accounting platform. Yield data for ground-fixed aerospace equipment is updated daily. In-orbit spacecraft data is synchronized per orbital period. Complete summary reports are generated on a monthly basis.
The standard structure of a single data entry includes equipment unique identifier, task batch, energy conversion cost, operation duration, total revenue, total allocated cost, and net profit fields. The unit of energy conversion cost is yuan, the unit of operation duration is hours, and all other monetary fields use yuan as the unit. Data files are stored in structured CSV or JSON format, with a single record corresponding to the revenue data of one piece of equipment during a single task cycle.
What constraints do these characteristics impose on conversation logs and auditing
The multi-source and update-frequency-differentiated characteristics of the data impose multiple constraints on conversation logs and auditing. The difference between daily updates for ground equipment and orbital period updates for in-orbit spacecraft requires logs to be archived across different time windows. Audits need to distinguish query permissions and time ranges for the two types of data. Structured data with multiple fields requires logs to fully record the calling, calculation, and modification processes of each field, to avoid being unable to trace the original basis of revenue accounting during audits. Calls to cross-system data sources require logs to associate the unique identifier of the corresponding interface, to ensure the traceability of data authenticity. The generation of monthly summary reports involves the superposition of multiple periods of data, and logs need to record the trigger time of the summary logic and the participating data source batches, to facilitate subsequent audit verification.
How to configure the settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
ENABLE_CONVERSATION_LOG | Full enable | Covers all conversation and API call scenarios related to aerospace equipment yield rates, to meet audit traceability requirements |
LOG_CLEANUP_CRON | 0 0 2 * * * | Executes log cleanup at 2:00 AM daily, matching the daily update rhythm of ground equipment, to avoid excessive occupation of storage resources |
LOG_QUERY_TIMEOUT | 600 seconds | Aerospace equipment data requires retrieval and aggregation across multiple data sources; 600 seconds covers query time consumption for most business scenarios |
AUDIT_FIELD_WHITELIST | Equipment unique identifier, task batch, energy conversion cost, operation duration, total revenue | Only records fields required for audits, reduces log redundancy, and complies with field requirements for military industry compliance audits |
API_LOG_RECORD_ENABLE | Only record requests with aerospace equipment identifiers | Focuses on core business scenarios, reducing storage and management costs for non-essential logs |
The parameter values provided on this page are common recommended starting points for configuration. Actual values are affected by material form, data volume, and business rules. Specific issues require case-by-case analysis, and it is recommended to test on your own samples before finalizing settings.
Three common misconfigurations
- Phenomenon: When calling the API to obtain aerospace equipment yield rate conversation logs, only conversations created via the web interface are returned, and conversation records created via the API cannot be obtained. Cause:
API_LOG_RECORD_ENABLEis not configured correctly, or is set to only record web requests, and does not cover API call scenarios. - Phenomenon: The console.log logs from the code execution module in the workflow cannot be viewed in the platform console. Cause: Log collection configuration for workflow nodes is not enabled, or the log storage path is not correctly pointed to the platform log directory.
- Phenomenon: When multiple users use the same application, non-creators cannot view their own historical conversation records. Cause: Conversation permission isolation rules are not configured, or the
AUDIT_FIELD_WHITELISTdoes not include the user identifier field, resulting in logs being unable to be grouped and traced by user.
How to confirm the configuration is valid
- Initiate an API call with an aerospace equipment identifier, check whether a corresponding record is generated in the log storage path, to confirm that the log collection configuration is effective.
- Use two different accounts to initiate conversation requests, verify that each account can only view its own historical conversations, to confirm that the permission isolation configuration is correct.
- Trigger a code execution node in the workflow, check whether the corresponding output exists in the platform log directory, to confirm that the workflow log collection configuration is correct.
- Manually execute a log cleanup task, verify that expired logs are properly cleaned up, to confirm that the scheduled cleanup configuration is effective.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-14.