EvoSpikeNet-Core Social Implementation App Catalog
Per-App Details
1. mineral_exploration
| Item | Content |
|---|---|
| Evaluation | A / 97.74 (Structure 15.00/15, Implementation 19.80/20, ProdReady 19.63/20, SDK 15.00/15, Testing 20.00/20, Coverage 8.31/10) |
| Product detail | An exploration product that combines geological, satellite, terrain, and candidate data to support promising mineral area extraction and report generation. Intended users are mineral exploration teams, geological engineers, investment decision makers, and field survey planners. It continuously ingests satellite imagery, terrain, geological maps, deposit candidates, field notes, and auxiliary data and provides prospectivity estimation, map visualization, candidate comparison, exploration reports, and operation through React UI as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | mineral exploration teams, geological engineers, investment decision makers, and field survey planners |
| Main inputs / integration data | satellite imagery, terrain, geological maps, deposit candidates, field notes, and auxiliary data |
| Core capabilities | prospectivity estimation, map visualization, candidate comparison, exploration reports, and operation through React UI |
| Use case / value | The primary scenario is for mineral exploration teams, geological engineers, investment decision makers, and field survey planners to review satellite imagery, terrain, geological maps, deposit candidates, field notes, and auxiliary data, use prospectivity estimation, map visualization, candidate comparison, exploration reports, and operation through React UI, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on satellite imagery, terrain, geological maps, deposit candidates, field notes, and auxiliary data. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | test evidence, SDK integration are leading, and integration/performance tests, production gate are already verified. Reinforcing coverage 83.1% is the next step to make the A-readiness substance explicit. The score is led by test evidence, SDK integration, with integration/performance tests, production gate, SDK runtime verification already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, production guard, implementation depth, test evidence, structure, production readiness, SDK integration, coverage. Reinforcement: coverage 83.1%. Prioritize coverage, production readiness first. |
| Next focus | React UI, 85% coverage, production gate, and Docker SDK API production smoke are verified; next focus is real-data API integration and SNN/spiking-lm training capability validation. |
2. ultra_large_scale_ai
| Item | Content |
|---|---|
| Evaluation | A / 97.70 (Structure 14.30/15, Implementation 19.10/20, ProdReady 20.00/20, SDK 15.00/15, Testing 20.00/20, Coverage 9.30/10) |
| Product detail | A platform product that integrates distributed execution, model operations, and resource monitoring for large-scale AI inference and training workloads. Intended users are AI platform teams, MLOps staff, researchers, cluster operators, and SREs. It continuously ingests models, job definitions, cluster state, metrics, datasets, and operation policies and provides distributed job management, model operations, resource monitoring, failure detection, and SLO checks as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | AI platform teams, MLOps staff, researchers, cluster operators, and SREs |
| Main inputs / integration data | models, job definitions, cluster state, metrics, datasets, and operation policies |
| Core capabilities | distributed job management, model operations, resource monitoring, failure detection, and SLO checks |
| Use case / value | The primary scenario is for AI platform teams, MLOps staff, researchers, cluster operators, and SREs to review models, job definitions, cluster state, metrics, datasets, and operation policies, use distributed job management, model operations, resource monitoring, failure detection, and SLO checks, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on models, job definitions, cluster state, metrics, datasets, and operation policies. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, test evidence are strongest, and integration/performance tests, coverage 93.0% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, test evidence, with integration/performance tests, coverage 93.0%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 93.0%, production guard, implementation depth, test evidence, structure, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Operations UI, E2E, coverage, and production gate are in place; next focus is real-machine load verification and operational SLO validation. |
3. humanoid
| Item | Content |
|---|---|
| Evaluation | A / 96.53 (Structure 15.00/15, Implementation 19.03/20, ProdReady 20.00/20, SDK 15.00/15, Testing 18.75/20, Coverage 8.75/10) |
| Product detail | A robotics platform that integrates control, perception, diagnostics, and simulation for humanoids together with APIs and operational workflows. Intended users are humanoid researchers, control developers, real-machine operators, and maintenance staff. It continuously ingests joint/pose data, sensors, behavior plans, diagnostic logs, and simulation conditions and provides control APIs, state diagnostics, behavior simulation, safety monitoring, and operation logs as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | humanoid researchers, control developers, real-machine operators, and maintenance staff |
| Main inputs / integration data | joint/pose data, sensors, behavior plans, diagnostic logs, and simulation conditions |
| Core capabilities | control APIs, state diagnostics, behavior simulation, safety monitoring, and operation logs |
| Use case / value | The primary scenario is for humanoid researchers, control developers, real-machine operators, and maintenance staff to review joint/pose data, sensors, behavior plans, diagnostic logs, and simulation conditions, use control APIs, state diagnostics, behavior simulation, safety monitoring, and operation logs, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on joint/pose data, sensors, behavior plans, diagnostic logs, and simulation conditions. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, SDK integration are strongest, and integration tests, coverage 87.5% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, SDK integration, with integration tests, coverage 87.5%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration tests, coverage 87.5%, production guard, implementation depth, test evidence, structure, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Frontend detection, 87.5% coverage, and the production gate are now in place; next focus is real HIL validation and operational SLO evidence. |
4. immersive_entertainment
| Item | Content |
|---|---|
| Evaluation | A / 96.34 (Structure 14.30/15, Implementation 17.90/20, ProdReady 20.00/20, SDK 15.00/15, Testing 19.50/20, Coverage 9.64/10) |
| Product detail | A product that integrates user reactions, spatial direction, and generated content to dynamically optimize immersive entertainment experiences. Intended users are event operators, XR/game creators, directors, and experience design teams. It continuously ingests user reactions, sensors, performance scenarios, audio/video assets, and experience logs and provides performance generation, reaction analysis, scene switching, experience quality monitoring, and execution tracing as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | event operators, XR/game creators, directors, and experience design teams |
| Main inputs / integration data | user reactions, sensors, performance scenarios, audio/video assets, and experience logs |
| Core capabilities | performance generation, reaction analysis, scene switching, experience quality monitoring, and execution tracing |
| Use case / value | The primary scenario is for event operators, XR/game creators, directors, and experience design teams to review user reactions, sensors, performance scenarios, audio/video assets, and experience logs, use performance generation, reaction analysis, scene switching, experience quality monitoring, and execution tracing, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on user reactions, sensors, performance scenarios, audio/video assets, and experience logs. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, SDK integration are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, SDK integration, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, implementation depth, test evidence, structure, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Operations UI, E2E, coverage, and production gate are in place; next focus is real-device integration and production SLO validation. |
5. takumi_network
| Item | Content |
|---|---|
| Evaluation | A / 94.82 (Structure 15.00/15, Implementation 17.32/20, ProdReady 20.00/20, SDK 15.00/15, Testing 18.50/20, Coverage 9.00/10) |
| Product detail | A knowledge product that accumulates expert tacit knowledge as Ba, RAG, and memory infrastructure, then connects it to retrieval, succession, and field support. Intended users are expert technicians, field education staff, knowledge managers, and R&D teams. It continuously ingests work records, dialogue, procedures, video/audio notes, tacit-knowledge tags, and reviews and provides knowledge retrieval, RAG responses, experience transfer, field support, and knowledge quality review as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | expert technicians, field education staff, knowledge managers, and R&D teams |
| Main inputs / integration data | work records, dialogue, procedures, video/audio notes, tacit-knowledge tags, and reviews |
| Core capabilities | knowledge retrieval, RAG responses, experience transfer, field support, and knowledge quality review |
| Use case / value | The primary scenario is for expert technicians, field education staff, knowledge managers, and R&D teams to review work records, dialogue, procedures, video/audio notes, tacit-knowledge tags, and reviews, use knowledge retrieval, RAG responses, experience transfer, field support, and knowledge quality review, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on work records, dialogue, procedures, video/audio notes, tacit-knowledge tags, and reviews. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, SDK integration are strongest, and integration/performance tests, coverage 90.0% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, SDK integration, with integration/performance tests, coverage 90.0%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 90.0%, production guard, implementation depth, test evidence, structure, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Operations UI, E2E tests, 90% coverage, production gate, and Docker SDK API production smoke are verified; next focus is model artifact bootstrap and field-data validation. |
6. real_time_language_translation
| Item | Content |
|---|---|
| Evaluation | A / 94.51 (Structure 14.30/15, Implementation 17.32/20, ProdReady 20.00/20, SDK 15.00/15, Testing 18.25/20, Coverage 9.64/10) |
| Product detail | A real-time translation product that translates speech and text with low latency while managing glossaries, quality, and conversation state. Intended users are meeting operators, interpretation support teams, call centers, and education/tourism services. It continuously ingests speech, text, glossaries, speaker information, conversation history, and quality feedback and provides low-latency translation, glossary application, speaker-specific history, quality monitoring, and translation evidence tracing as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | meeting operators, interpretation support teams, call centers, and education/tourism services |
| Main inputs / integration data | speech, text, glossaries, speaker information, conversation history, and quality feedback |
| Core capabilities | low-latency translation, glossary application, speaker-specific history, quality monitoring, and translation evidence tracing |
| Use case / value | The primary scenario is for meeting operators, interpretation support teams, call centers, and education/tourism services to review speech, text, glossaries, speaker information, conversation history, and quality feedback, use low-latency translation, glossary application, speaker-specific history, quality monitoring, and translation evidence tracing, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on speech, text, glossaries, speaker information, conversation history, and quality feedback. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, SDK integration are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, SDK integration, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, implementation depth, test evidence, structure, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | SDK integration and coverage are strong; next focus is low-latency UI and glossary application tracing. |
7. climate_change_prediction
| Item | Content |
|---|---|
| Evaluation | A / 94.41 (Structure 15.00/15, Implementation 14.77/20, ProdReady 20.00/20, SDK 15.00/15, Testing 20.00/20, Coverage 9.64/10) |
| Product detail | An analytics product that combines weather, ocean, satellite, and environmental statistics to forecast climate-change scenarios and regional impacts. Intended users are climate researchers, municipalities, infrastructure operators, environmental policy teams, and risk analysts. It continuously ingests weather time series, satellite imagery, emission scenarios, ocean/topography data, and regional statistics and provides scenario comparison, regional risk prediction, anomaly trend detection, and explainable forecast reports as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | climate researchers, municipalities, infrastructure operators, environmental policy teams, and risk analysts |
| Main inputs / integration data | weather time series, satellite imagery, emission scenarios, ocean/topography data, and regional statistics |
| Core capabilities | scenario comparison, regional risk prediction, anomaly trend detection, and explainable forecast reports |
| Use case / value | The primary scenario is for climate researchers, municipalities, infrastructure operators, environmental policy teams, and risk analysts to review weather time series, satellite imagery, emission scenarios, ocean/topography data, and regional statistics, use scenario comparison, regional risk prediction, anomaly trend detection, and explainable forecast reports, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on weather time series, satellite imagery, emission scenarios, ocean/topography data, and regional statistics. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, test evidence are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, test evidence, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, test evidence, structure, implementation depth, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Coverage and tests are strong; next focus is production operation, real-data integration, and prediction UI. |
8. personalized_education_platform
| Item | Content |
|---|---|
| Evaluation | A / 94.16 (Structure 14.30/15, Implementation 15.22/20, ProdReady 20.00/20, SDK 15.00/15, Testing 20.00/20, Coverage 9.64/10) |
| Product detail | An education product that uses learning history, comprehension level, and learning-material metadata to recommend materials and support progress for each learner. Intended users are learners, teachers, educational institutions, material creators, and learning support staff. It continuously ingests learning logs, test results, materials, goals, comprehension levels, and feedback and provides personalized material recommendation, comprehension estimation, learning plans, progress monitoring, and intervention suggestions as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | learners, teachers, educational institutions, material creators, and learning support staff |
| Main inputs / integration data | learning logs, test results, materials, goals, comprehension levels, and feedback |
| Core capabilities | personalized material recommendation, comprehension estimation, learning plans, progress monitoring, and intervention suggestions |
| Use case / value | The primary scenario is for learners, teachers, educational institutions, material creators, and learning support staff to review learning logs, test results, materials, goals, comprehension levels, and feedback, use personalized material recommendation, comprehension estimation, learning plans, progress monitoring, and intervention suggestions, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on learning logs, test results, materials, goals, comprehension levels, and feedback. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, test evidence are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, test evidence, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, test evidence, structure, implementation depth, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Tests and coverage are strong; next focus is production readiness and learner UI. |
9. financial_trading_optimization
| Item | Content |
|---|---|
| Evaluation | A / 94.14 (Structure 14.30/15, Implementation 17.70/20, ProdReady 20.00/20, SDK 13.00/15, Testing 19.50/20, Coverage 9.64/10) |
| Product detail | A financial optimization product that integrates market data, risk constraints, and execution history to support trade candidates, positions, and risk approval. Intended users are traders, quants, risk managers, compliance staff, and operations monitors. It continuously ingests price/order-book/execution data, risk constraints, portfolios, news/indicators, and order history and provides trade candidate generation, risk evaluation, order simulation, approval workflow, and audit logs as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | traders, quants, risk managers, compliance staff, and operations monitors |
| Main inputs / integration data | price/order-book/execution data, risk constraints, portfolios, news/indicators, and order history |
| Core capabilities | trade candidate generation, risk evaluation, order simulation, approval workflow, and audit logs |
| Use case / value | The primary scenario is for traders, quants, risk managers, compliance staff, and operations monitors to review price/order-book/execution data, risk constraints, portfolios, news/indicators, and order history, use trade candidate generation, risk evaluation, order simulation, approval workflow, and audit logs, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on price/order-book/execution data, risk constraints, portfolios, news/indicators, and order history. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, test evidence are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, test evidence, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, implementation depth, test evidence, structure, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Operations UI, E2E, coverage, and production gate are in place; next focus is real venue integration and regulatory audit evidence. |
10. cybersecurity_monitoring_system
| Item | Content |
|---|---|
| Evaluation | A / 93.70 (Structure 15.00/15, Implementation 14.06/20, ProdReady 20.00/20, SDK 15.00/15, Testing 20.00/20, Coverage 9.64/10) |
| Product detail | A monitoring platform that integrates logs, events, and threat intelligence to support SOC detection, prioritization, and response records. Intended users are SOC analysts, CSIRT members, security operators, and auditors. It continuously ingests authentication logs, network events, EDR/SIEM alerts, threat IOCs, and response history and provides threat detection, alert triage, response workflow, audit trail, and risk reporting as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | SOC analysts, CSIRT members, security operators, and auditors |
| Main inputs / integration data | authentication logs, network events, EDR/SIEM alerts, threat IOCs, and response history |
| Core capabilities | threat detection, alert triage, response workflow, audit trail, and risk reporting |
| Use case / value | The primary scenario is for SOC analysts, CSIRT members, security operators, and auditors to review authentication logs, network events, EDR/SIEM alerts, threat IOCs, and response history, use threat detection, alert triage, response workflow, audit trail, and risk reporting, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on authentication logs, network events, EDR/SIEM alerts, threat IOCs, and response history. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, test evidence are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, test evidence, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, test evidence, structure, implementation depth, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Tests and operational readiness are strong; next focus is alert triage UI and response automation. |
11. quantum_neuro_fusion
| Item | Content |
|---|---|
| Evaluation | A / 93.70 (Structure 14.30/15, Implementation 17.61/20, ProdReady 20.00/20, SDK 15.00/15, Testing 17.15/20, Coverage 9.64/10) |
| Product detail | A research product that manages quantum circuit experiments and neural processing under the same experiment framework to support comparison, visualization, and reproducibility checks. Intended users are quantum AI researchers, experiment operators, algorithm developers, and reviewers. It continuously ingests quantum circuits, neural models, experiment conditions, measurement results, and comparison metrics and provides experiment design, quantum/neural processing comparison, result visualization, reruns, and auditable experiment logs as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | quantum AI researchers, experiment operators, algorithm developers, and reviewers |
| Main inputs / integration data | quantum circuits, neural models, experiment conditions, measurement results, and comparison metrics |
| Core capabilities | experiment design, quantum/neural processing comparison, result visualization, reruns, and auditable experiment logs |
| Use case / value | The primary scenario is for quantum AI researchers, experiment operators, algorithm developers, and reviewers to review quantum circuits, neural models, experiment conditions, measurement results, and comparison metrics, use experiment design, quantum/neural processing comparison, result visualization, reruns, and auditable experiment logs, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on quantum circuits, neural models, experiment conditions, measurement results, and comparison metrics. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, SDK integration are strongest, and integration tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, SDK integration, with integration tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration tests, coverage 96.4%, production guard, implementation depth, structure, production readiness, SDK integration, test evidence, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Implementation depth is high; next focus is experiment UI, backend state monitoring, and result comparison. |
12. smart_city_infrastructure
| Item | Content |
|---|---|
| Evaluation | A / 93.66 (Structure 15.00/15, Implementation 14.88/20, ProdReady 19.14/20, SDK 15.00/15, Testing 20.00/20, Coverage 9.64/10) |
| Product detail | A smart-city platform that integrates urban facilities, traffic, environment, and maintenance events to support infrastructure anomaly response, maintenance planning, and operational decisions. Intended users are municipalities, city OS operators, infrastructure maintenance companies, and disaster/environment teams. It continuously ingests facility sensors, traffic/environmental data, maintenance history, reports, maps, and priority rules and provides anomaly detection, maintenance prioritization, city dashboards, response history, and SLO monitoring as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | municipalities, city OS operators, infrastructure maintenance companies, and disaster/environment teams |
| Main inputs / integration data | facility sensors, traffic/environmental data, maintenance history, reports, maps, and priority rules |
| Core capabilities | anomaly detection, maintenance prioritization, city dashboards, response history, and SLO monitoring |
| Use case / value | The primary scenario is for municipalities, city OS operators, infrastructure maintenance companies, and disaster/environment teams to review facility sensors, traffic/environmental data, maintenance history, reports, maps, and priority rules, use anomaly detection, maintenance prioritization, city dashboards, response history, and SLO monitoring, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on facility sensors, traffic/environmental data, maintenance history, reports, maps, and priority rules. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | test evidence, SDK integration are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by test evidence, SDK integration, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, test evidence, structure, implementation depth, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Tests and SDK integration are strong; next focus is production guards and city operations dashboard. |
13. autonomous_vehicle_system
| Item | Content |
|---|---|
| Evaluation | A / 93.58 (Structure 15.00/15, Implementation 15.19/20, ProdReady 20.00/20, SDK 15.00/15, Testing 18.75/20, Coverage 9.64/10) |
| Product detail | A platform that integrates vehicle telemetry, driving plans, road conditions, and safety constraints to support autonomous fleet execution and monitoring. Intended users are autonomous driving developers, fleet operators, safety monitoring teams, and mobility providers. It continuously ingests vehicle state, maps, routes, traffic conditions, obstacle detections, operation plans, and incident logs and provides route optimization, safety-stop judgment, driving-state monitoring, simulator integration, and operation audit as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | autonomous driving developers, fleet operators, safety monitoring teams, and mobility providers |
| Main inputs / integration data | vehicle state, maps, routes, traffic conditions, obstacle detections, operation plans, and incident logs |
| Core capabilities | route optimization, safety-stop judgment, driving-state monitoring, simulator integration, and operation audit |
| Use case / value | The primary scenario is for autonomous driving developers, fleet operators, safety monitoring teams, and mobility providers to review vehicle state, maps, routes, traffic conditions, obstacle detections, operation plans, and incident logs, use route optimization, safety-stop judgment, driving-state monitoring, simulator integration, and operation audit, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on vehicle state, maps, routes, traffic conditions, obstacle detections, operation plans, and incident logs. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, SDK integration are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, SDK integration, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, test evidence, structure, implementation depth, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Upper B grade; next focus is production guards, route UI, and real vehicle or simulator integration. |
14. space_exploration_support
| Item | Content |
|---|---|
| Evaluation | A / 93.55 (Structure 14.30/15, Implementation 17.81/20, ProdReady 20.00/20, SDK 13.00/15, Testing 18.80/20, Coverage 9.64/10) |
| Product detail | A space exploration platform that integrates spacecraft telemetry, observation plans, science goals, and communication constraints to support mission planning and replanning. Intended users are mission control, planetary scientists, spacecraft operators, and observation planners. It continuously ingests telemetry, observation candidates, communication windows, power/thermal constraints, and science priorities and provides observation planning, mission replanning, anomaly monitoring, priority adjustment, and control UI as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | mission control, planetary scientists, spacecraft operators, and observation planners |
| Main inputs / integration data | telemetry, observation candidates, communication windows, power/thermal constraints, and science priorities |
| Core capabilities | observation planning, mission replanning, anomaly monitoring, priority adjustment, and control UI |
| Use case / value | The primary scenario is for mission control, planetary scientists, spacecraft operators, and observation planners to review telemetry, observation candidates, communication windows, power/thermal constraints, and science priorities, use observation planning, mission replanning, anomaly monitoring, priority adjustment, and control UI, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on telemetry, observation candidates, communication windows, power/thermal constraints, and science priorities. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, coverage are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, coverage, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, implementation depth, test evidence, structure, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | SDK integration and operational readiness are sufficient; next focus is mission control UI and real-data connection. |
15. smart_traffic_management
| Item | Content |
|---|---|
| Evaluation | A / 93.43 (Structure 14.30/15, Implementation 17.14/20, ProdReady 20.00/20, SDK 15.00/15, Testing 17.35/20, Coverage 9.64/10) |
| Product detail | A traffic control product that uses traffic sensors, signal control, incident information, and road conditions to optimize urban traffic flow and emergency response. Intended users are traffic control centers, municipalities, road operators, and emergency response teams. It continuously ingests traffic volume, speed, signal state, incident/construction information, road networks, and weather and provides signal optimization, congestion prediction, incident response, green-wave control, and control-room screens as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | traffic control centers, municipalities, road operators, and emergency response teams |
| Main inputs / integration data | traffic volume, speed, signal state, incident/construction information, road networks, and weather |
| Core capabilities | signal optimization, congestion prediction, incident response, green-wave control, and control-room screens |
| Use case / value | The primary scenario is for traffic control centers, municipalities, road operators, and emergency response teams to review traffic volume, speed, signal state, incident/construction information, road networks, and weather, use signal optimization, congestion prediction, incident response, green-wave control, and control-room screens, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on traffic volume, speed, signal state, incident/construction information, road networks, and weather. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, SDK integration are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, SDK integration, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, implementation depth, structure, production readiness, SDK integration, test evidence, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Production readiness and SDK integration are strong; next focus is control-room UI and real traffic-signal integration verification. |
16. social_media_recommendation
| Item | Content |
|---|---|
| Evaluation | A / 93.33 (Structure 14.30/15, Implementation 17.59/20, ProdReady 20.00/20, SDK 13.00/15, Testing 18.80/20, Coverage 9.64/10) |
| Product detail | A social recommendation platform that integrates posts, user reactions, and safety filters to manage ranking, reasons, and risks. Intended users are SNS operators, recommendation engineers, safety reviewers, and content operators. It continuously ingests posts, user behavior, relationship graphs, safety labels, feedback, and policies and provides recommendation ranking, reason display, safety filtering, reaction analysis, and audit logs as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | SNS operators, recommendation engineers, safety reviewers, and content operators |
| Main inputs / integration data | posts, user behavior, relationship graphs, safety labels, feedback, and policies |
| Core capabilities | recommendation ranking, reason display, safety filtering, reaction analysis, and audit logs |
| Use case / value | The primary scenario is for SNS operators, recommendation engineers, safety reviewers, and content operators to review posts, user behavior, relationship graphs, safety labels, feedback, and policies, use recommendation ranking, reason display, safety filtering, reaction analysis, and audit logs, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on posts, user behavior, relationship graphs, safety labels, feedback, and policies. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, coverage are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, coverage, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, implementation depth, test evidence, structure, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Operational readiness and coverage are sufficient; next focus is recommendation explanation UI and safety audit screen. |
17. dream_realization_simulator
| Item | Content |
|---|---|
| Evaluation | A / 92.83 (Structure 14.30/15, Implementation 16.09/20, ProdReady 20.00/20, SDK 15.00/15, Testing 17.80/20, Coverage 9.64/10) |
| Product detail | A personal and organizational support product that continuously reevaluates feasible plans, alternative routes, and achievement probability from goals, constraints, and daily progress. Intended users are individual users, coaches, education staff, business planners, and team leaders. It continuously ingests goals, deadlines, constraints, progress logs, resources, action history, and reflection notes and provides achievement plan generation, progress-delta analysis, replanning, risk detection, and execution tracing as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | individual users, coaches, education staff, business planners, and team leaders |
| Main inputs / integration data | goals, deadlines, constraints, progress logs, resources, action history, and reflection notes |
| Core capabilities | achievement plan generation, progress-delta analysis, replanning, risk detection, and execution tracing |
| Use case / value | The primary scenario is for individual users, coaches, education staff, business planners, and team leaders to review goals, deadlines, constraints, progress logs, resources, action history, and reflection notes, use achievement plan generation, progress-delta analysis, replanning, risk detection, and execution tracing, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on goals, deadlines, constraints, progress logs, resources, action history, and reflection notes. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, SDK integration are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, SDK integration, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, implementation depth, structure, production readiness, SDK integration, test evidence, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Progress operations UI is implemented; next focus is real session-data integration and plan-delta validation. |
18. industrial_iot_optimization
| Item | Content |
|---|---|
| Evaluation | A / 92.76 (Structure 15.00/15, Implementation 14.74/20, ProdReady 20.00/20, SDK 14.50/15, Testing 20.00/20, Coverage 8.52/10) |
| Product detail | An industrial IoT platform that integrates equipment sensors, operation logs, and maintenance information to support anomaly prediction, optimized operation, and maintenance planning. Intended users are factory operators, equipment maintenance teams, quality managers, production engineers, and field supervisors. It continuously ingests equipment sensors, utilization rates, anomaly logs, maintenance history, production plans, and environmental data and provides anomaly detection, predictive maintenance, operating-condition optimization, equipment monitoring, and maintenance reporting as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | factory operators, equipment maintenance teams, quality managers, production engineers, and field supervisors |
| Main inputs / integration data | equipment sensors, utilization rates, anomaly logs, maintenance history, production plans, and environmental data |
| Core capabilities | anomaly detection, predictive maintenance, operating-condition optimization, equipment monitoring, and maintenance reporting |
| Use case / value | The primary scenario is for factory operators, equipment maintenance teams, quality managers, production engineers, and field supervisors to review equipment sensors, utilization rates, anomaly logs, maintenance history, production plans, and environmental data, use anomaly detection, predictive maintenance, operating-condition optimization, equipment monitoring, and maintenance reporting, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on equipment sensors, utilization rates, anomaly logs, maintenance history, production plans, and environmental data. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, test evidence are strongest, and integration/performance tests, coverage 85.2% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, test evidence, with integration/performance tests, coverage 85.2%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 85.2%, production guard, test evidence, structure, implementation depth, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Equipment operations UI is implemented; next focus is real telemetry integration and maintenance SLO validation. |
19. alien_life_exploration_support
| Item | Content |
|---|---|
| Evaluation | A / 92.57 (Structure 14.30/15, Implementation 16.28/20, ProdReady 20.00/20, SDK 15.00/15, Testing 17.35/20, Coverage 9.64/10) |
| Product detail | An exploration support product that integrates biosignature candidates from spacecraft, telescopes, spectroscopy, and geological samples so research teams can track hypotheses, evidence, and falsification conditions. Intended users are astrobiologists, planetary scientists, observation planners, and peer-review teams. It continuously ingests observation spectra, imagery, geological and chemical samples, mission plans, and candidate signature definitions and provides biosignature candidate prioritization, observation replanning, evidence-chain management, and review report generation as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | astrobiologists, planetary scientists, observation planners, and peer-review teams |
| Main inputs / integration data | observation spectra, imagery, geological and chemical samples, mission plans, and candidate signature definitions |
| Core capabilities | biosignature candidate prioritization, observation replanning, evidence-chain management, and review report generation |
| Use case / value | The primary scenario is for astrobiologists, planetary scientists, observation planners, and peer-review teams to review observation spectra, imagery, geological and chemical samples, mission plans, and candidate signature definitions, use biosignature candidate prioritization, observation replanning, evidence-chain management, and review report generation, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on observation spectra, imagery, geological and chemical samples, mission plans, and candidate signature definitions. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, SDK integration are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, SDK integration, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, implementation depth, structure, production readiness, SDK integration, test evidence, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Observation review UI is implemented; next focus is real observation-data integration and review workflow validation. |
20. genetic_analysis_support
| Item | Content |
|---|---|
| Evaluation | A / 92.51 (Structure 14.30/15, Implementation 14.77/20, ProdReady 20.00/20, SDK 15.00/15, Testing 18.80/20, Coverage 9.64/10) |
| Product detail | An analysis support product that integrates genomic sequences, variants, and annotation data to organize candidate variants and evidence for research or clinical review. Intended users are genome researchers, clinical laboratory staff, physicians, and bioinformatics specialists. It continuously ingests FASTQ/VCF, reference genomes, variant annotations, phenotypes, and review comments and provides variant detection support, annotation, candidate prioritization, review history, and report generation as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | genome researchers, clinical laboratory staff, physicians, and bioinformatics specialists |
| Main inputs / integration data | FASTQ/VCF, reference genomes, variant annotations, phenotypes, and review comments |
| Core capabilities | variant detection support, annotation, candidate prioritization, review history, and report generation |
| Use case / value | The primary scenario is for genome researchers, clinical laboratory staff, physicians, and bioinformatics specialists to review FASTQ/VCF, reference genomes, variant annotations, phenotypes, and review comments, use variant detection support, annotation, candidate prioritization, review history, and report generation, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on FASTQ/VCF, reference genomes, variant annotations, phenotypes, and review comments. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, SDK integration are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, SDK integration, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, test evidence, structure, implementation depth, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Genomics analysis UI is implemented; next focus is real sequence ingestion and variant-review operations validation. |
21. location_aware_team_robotics
| Item | Content |
|---|---|
| Evaluation | A / 92.40 (Structure 14.30/15, Implementation 15.96/20, ProdReady 20.00/20, SDK 13.00/15, Testing 19.50/20, Coverage 9.64/10) |
| Product detail | A cooperative control product that uses location information and robot fleet state to manage team mission assignment, routes, interference avoidance, and safety monitoring. Intended users are warehouse/factory control teams, swarm robotics researchers, field operators, and safety managers. It continuously ingests robot locations, maps, missions, obstacles, communication state, and safety zones and provides team formation, route adjustment, interference avoidance, mission progress monitoring, and map UI integration as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | warehouse/factory control teams, swarm robotics researchers, field operators, and safety managers |
| Main inputs / integration data | robot locations, maps, missions, obstacles, communication state, and safety zones |
| Core capabilities | team formation, route adjustment, interference avoidance, mission progress monitoring, and map UI integration |
| Use case / value | The primary scenario is for warehouse/factory control teams, swarm robotics researchers, field operators, and safety managers to review robot locations, maps, missions, obstacles, communication state, and safety zones, use team formation, route adjustment, interference avoidance, mission progress monitoring, and map UI integration, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on robot locations, maps, missions, obstacles, communication state, and safety zones. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, test evidence are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, test evidence, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, test evidence, structure, implementation depth, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Team robotics UI is implemented; next focus is real robot integration and map or formation visualization validation. |
22. precision_agriculture_optimization
| Item | Content |
|---|---|
| Evaluation | A / 92.13 (Structure 14.30/15, Implementation 16.84/20, ProdReady 20.00/20, SDK 13.00/15, Testing 18.35/20, Coverage 9.64/10) |
| Product detail | An agriculture support product that integrates field sensors, weather, imagery, and crop state to optimize irrigation, fertilization, pest control, and yield. Intended users are agricultural corporations, farm managers, extension workers, and smart-agriculture vendors. It continuously ingests soil/moisture sensors, weather, field imagery, crop state, work plans, and yield history and provides field condition monitoring, fertilization/irrigation suggestions, yield prediction, work planning, and map UI as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | agricultural corporations, farm managers, extension workers, and smart-agriculture vendors |
| Main inputs / integration data | soil/moisture sensors, weather, field imagery, crop state, work plans, and yield history |
| Core capabilities | field condition monitoring, fertilization/irrigation suggestions, yield prediction, work planning, and map UI |
| Use case / value | The primary scenario is for agricultural corporations, farm managers, extension workers, and smart-agriculture vendors to review soil/moisture sensors, weather, field imagery, crop state, work plans, and yield history, use field condition monitoring, fertilization/irrigation suggestions, yield prediction, work planning, and map UI, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on soil/moisture sensors, weather, field imagery, crop state, work plans, and yield history. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, coverage are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, coverage, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, implementation depth, test evidence, structure, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Field operations UI is implemented; next focus is real sensor integration and yield-forecast operations validation. |
23. medical_quantum_federated_learning_platform
| Item | Content |
|---|---|
| Evaluation | A / 91.54 (Structure 14.30/15, Implementation 18.24/20, ProdReady 17.76/20, SDK 15.00/15, Testing 16.60/20, Coverage 9.64/10) |
| Product detail | A medical AI research platform for federated learning and quantum aggregation experiments across institutions without directly centralizing their data. Intended users are medical AI researchers, hospital data administrators, privacy officers, and joint research teams. It continuously ingests site-level training metadata, model updates, privacy settings, quantum aggregation parameters, and audit trails and provides federated learning management, quantum aggregation experiments, privacy auditing, and site-level status monitoring as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | medical AI researchers, hospital data administrators, privacy officers, and joint research teams |
| Main inputs / integration data | site-level training metadata, model updates, privacy settings, quantum aggregation parameters, and audit trails |
| Core capabilities | federated learning management, quantum aggregation experiments, privacy auditing, and site-level status monitoring |
| Use case / value | The primary scenario is for medical AI researchers, hospital data administrators, privacy officers, and joint research teams to review site-level training metadata, model updates, privacy settings, quantum aggregation parameters, and audit trails, use federated learning management, quantum aggregation experiments, privacy auditing, and site-level status monitoring, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on site-level training metadata, model updates, privacy settings, quantum aggregation parameters, and audit trails. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | SDK integration, coverage are strongest, and integration tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by SDK integration, coverage, with integration tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration tests, coverage 96.4%, implementation depth, structure, production readiness, SDK integration, test evidence, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Federated learning operations UI is implemented; next focus is real institution integration and privacy-audit workflow validation. |
24. medical_diagnostic_assistant
| Item | Content |
|---|---|
| Evaluation | A / 90.97 (Structure 14.30/15, Implementation 14.70/20, ProdReady 18.33/20, SDK 15.00/15, Testing 19.00/20, Coverage 9.64/10) |
| Product detail | A medical support product that integrates symptoms, lab values, image metadata, and clinical notes to present diagnostic candidates and evidence for physician review. Intended users are physicians, clinical laboratory staff, medical AI evaluators, and hospital information system teams. It continuously ingests symptoms, lab values, image metadata, medical history, clinical guidelines, and review results and provides diagnostic candidate presentation, evidence explanation, contraindication/risk checks, physician review, and audit logs as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | physicians, clinical laboratory staff, medical AI evaluators, and hospital information system teams |
| Main inputs / integration data | symptoms, lab values, image metadata, medical history, clinical guidelines, and review results |
| Core capabilities | diagnostic candidate presentation, evidence explanation, contraindication/risk checks, physician review, and audit logs |
| Use case / value | The primary scenario is for physicians, clinical laboratory staff, medical AI evaluators, and hospital information system teams to review symptoms, lab values, image metadata, medical history, clinical guidelines, and review results, use diagnostic candidate presentation, evidence explanation, contraindication/risk checks, physician review, and audit logs, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on symptoms, lab values, image metadata, medical history, clinical guidelines, and review results. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | SDK integration, coverage are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by SDK integration, coverage, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, test evidence, structure, implementation depth, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Clinical operations UI is implemented; next focus is real case integration and physician-review workflow validation. |
25. logistics_routing_app
| Item | Content |
|---|---|
| Evaluation | A / 90.93 (Structure 13.50/15, Implementation 16.04/20, ProdReady 20.00/20, SDK 15.00/15, Testing 16.75/20, Coverage 9.64/10) |
| Product detail | A logistics product that combines orders, vehicles, warehouses, traffic, and time constraints to optimize delivery routes and dispatch decisions. Intended users are logistics managers, dispatchers, warehouse operators, and last-mile providers. It continuously ingests orders, vehicle capacity, destinations, time windows, traffic, warehouse inventory, and driver constraints and provides dispatch optimization, route recalculation, delay risk detection, delivery status monitoring, and plan comparison as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | logistics managers, dispatchers, warehouse operators, and last-mile providers |
| Main inputs / integration data | orders, vehicle capacity, destinations, time windows, traffic, warehouse inventory, and driver constraints |
| Core capabilities | dispatch optimization, route recalculation, delay risk detection, delivery status monitoring, and plan comparison |
| Use case / value | The primary scenario is for logistics managers, dispatchers, warehouse operators, and last-mile providers to review orders, vehicle capacity, destinations, time windows, traffic, warehouse inventory, and driver constraints, use dispatch optimization, route recalculation, delay risk detection, delivery status monitoring, and plan comparison, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on orders, vehicle capacity, destinations, time windows, traffic, warehouse inventory, and driver constraints. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, SDK integration are strongest, and integration tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, SDK integration, with integration tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration tests, coverage 96.4%, production guard, implementation depth, structure, production readiness, SDK integration, test evidence, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Dispatch operations UI, E2E, coverage, and production gate are in place; next focus is real traffic API integration and operational SLOs. |
26. eeg_brain_simulation
| Item | Content |
|---|---|
| Evaluation | A / 90.76 (Structure 14.30/15, Implementation 14.02/20, ProdReady 20.00/20, SDK 15.00/15, Testing 17.80/20, Coverage 9.64/10) |
| Product detail | A research support product that compares brain activity features, responses, and simulation results using EEG signals and experimental conditions. Intended users are neuroscience researchers, clinical researchers, experiment operators, and data analysts. It continuously ingests EEG waveforms, event markers, subject conditions, experiment protocols, and analysis parameters and provides waveform analysis, feature extraction, condition comparison, simulation, and experiment result reporting as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | neuroscience researchers, clinical researchers, experiment operators, and data analysts |
| Main inputs / integration data | EEG waveforms, event markers, subject conditions, experiment protocols, and analysis parameters |
| Core capabilities | waveform analysis, feature extraction, condition comparison, simulation, and experiment result reporting |
| Use case / value | The primary scenario is for neuroscience researchers, clinical researchers, experiment operators, and data analysts to review EEG waveforms, event markers, subject conditions, experiment protocols, and analysis parameters, use waveform analysis, feature extraction, condition comparison, simulation, and experiment result reporting, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on EEG waveforms, event markers, subject conditions, experiment protocols, and analysis parameters. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, SDK integration are strongest, and integration/performance tests, coverage 96.4% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, SDK integration, with integration/performance tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 96.4%, production guard, structure, implementation depth, production readiness, SDK integration, test evidence, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | EEG experiment operations UI is implemented; next focus is real waveform-data integration and analysis workflow validation. |
27. brain_machine_interface
| Item | Content |
|---|---|
| Evaluation | A / 90.74 (Structure 14.30/15, Implementation 18.03/20, ProdReady 20.00/20, SDK 10.50/15, Testing 18.80/20, Coverage 9.11/10) |
| Product detail | A BMI research and operations product that links neural signals with external device control while handling stimulation, feedback, and safety monitoring. Intended users are neural engineering researchers, clinical research teams, rehabilitation staff, and device developers. It continuously ingests neural signals, stimulation parameters, device state, subject protocols, and safety thresholds and provides signal feature extraction, control conversion, stimulation/feedback management, safety monitoring, and experiment log management as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | neural engineering researchers, clinical research teams, rehabilitation staff, and device developers |
| Main inputs / integration data | neural signals, stimulation parameters, device state, subject protocols, and safety thresholds |
| Core capabilities | signal feature extraction, control conversion, stimulation/feedback management, safety monitoring, and experiment log management |
| Use case / value | The primary scenario is for neural engineering researchers, clinical research teams, rehabilitation staff, and device developers to review neural signals, stimulation parameters, device state, subject protocols, and safety thresholds, use signal feature extraction, control conversion, stimulation/feedback management, safety monitoring, and experiment log management, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on neural signals, stimulation parameters, device state, subject protocols, and safety thresholds. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, structure are strongest, and integration/performance tests, coverage 91.1% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by production readiness, structure, with integration/performance tests, coverage 91.1%, production gate already verified. Strengths: implemented UI, integration/performance tests, coverage 91.1%, production guard, implementation depth, test evidence, structure, production readiness, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | BMI safety operations UI is implemented; next focus is real EEG stream integration and clinical safety validation. |
28. autonomous_robotics_control
| Item | Content |
|---|---|
| Evaluation | A / 90.70 (Structure 15.00/15, Implementation 15.14/20, ProdReady 17.03/20, SDK 15.00/15, Testing 20.00/20, Coverage 8.53/10) |
| Product detail | A control platform that integrates sensor inputs, motion plans, and safety constraints to manage autonomous robot decisions and emergency stops. Intended users are robot developers, operations monitors, equipment maintenance teams, and safety managers. It continuously ingests LiDAR, camera, IMU, route plans, control parameters, work-area definitions, and safety policies and provides motion planning, sensor fusion, safety stop control, control logs, and simulation/real-machine switching as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | robot developers, operations monitors, equipment maintenance teams, and safety managers |
| Main inputs / integration data | LiDAR, camera, IMU, route plans, control parameters, work-area definitions, and safety policies |
| Core capabilities | motion planning, sensor fusion, safety stop control, control logs, and simulation/real-machine switching |
| Use case / value | The primary scenario is for robot developers, operations monitors, equipment maintenance teams, and safety managers to review LiDAR, camera, IMU, route plans, control parameters, work-area definitions, and safety policies, use motion planning, sensor fusion, safety stop control, control logs, and simulation/real-machine switching, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on LiDAR, camera, IMU, route plans, control parameters, work-area definitions, and safety policies. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | test evidence, SDK integration are strongest, and integration/performance tests, coverage 85.3% are already verified. The product is ready for real-use validation and production-operation verification. The score is led by test evidence, SDK integration, with integration/performance tests, coverage 85.3%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, coverage 85.3%, test evidence, structure, implementation depth, production readiness, SDK integration, coverage. Reinforcement: real-use data, operational SLO validation, and real-machine load verification. |
| Next focus | Robotics control UI is implemented; next focus is real robot command integration and safety SLO validation. |
29. video_scene_app
| Item | Content |
|---|---|
| Evaluation | A / 90.32 (Structure 14.30/15, Implementation 16.29/20, ProdReady 20.00/20, SDK 15.00/15, Testing 19.50/20, Coverage 5.23/10) |
| Product detail | An early prototype for video scene analysis or generation that is expected to handle input video, scene-level features, and generated or analyzed results. Intended users are video creators, analysts, content operators, and R&D teams. It continuously ingests videos, frames, scene boundaries, metadata, and analysis/generation parameters and provides scene segmentation, feature extraction, generation candidates, result review, and evaluation reports as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | video creators, analysts, content operators, and R&D teams |
| Main inputs / integration data | videos, frames, scene boundaries, metadata, and analysis/generation parameters |
| Core capabilities | scene segmentation, feature extraction, generation candidates, result review, and evaluation reports |
| Use case / value | The primary scenario is for video creators, analysts, content operators, and R&D teams to review videos, frames, scene boundaries, metadata, and analysis/generation parameters, use scene segmentation, feature extraction, generation candidates, result review, and evaluation reports, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on videos, frames, scene boundaries, metadata, and analysis/generation parameters. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, SDK integration are leading, and integration/performance tests, production gate are already verified. Reinforcing coverage 52.3% is the next step to make the A-readiness substance explicit. The score is led by production readiness, SDK integration, with integration/performance tests, production gate, SDK runtime verification already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, production guard, implementation depth, test evidence, structure, production readiness, SDK integration. Reinforcement: coverage 52.3%. Prioritize coverage, implementation depth first. |
| Next focus | Highest-priority improvement target; implementation depth, tests, SDK integration, coverage, and specification cleanup are required. |
30. avatar_coevolution
| Item | Content |
|---|---|
| Evaluation | A / 90.02 (Structure 14.30/15, Implementation 15.38/20, ProdReady 20.00/20, SDK 15.00/15, Testing 15.70/20, Coverage 9.64/10) |
| Product detail | A conversational experience platform that uses user reactions, dialogue history, and expression/behavior patterns to safely co-evolve avatar behavior. Intended users are avatar service operators, UX researchers, dialogue designers, and content creators. It continuously ingests dialogue logs, reaction metrics, facial/voice features, behavior candidates, and safety policies and provides behavior candidate generation, reaction learning, safety filtering, A/B evaluation, and avatar state visualization as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | avatar service operators, UX researchers, dialogue designers, and content creators |
| Main inputs / integration data | dialogue logs, reaction metrics, facial/voice features, behavior candidates, and safety policies |
| Core capabilities | behavior candidate generation, reaction learning, safety filtering, A/B evaluation, and avatar state visualization |
| Use case / value | The primary scenario is for avatar service operators, UX researchers, dialogue designers, and content creators to review dialogue logs, reaction metrics, facial/voice features, behavior candidates, and safety policies, use behavior candidate generation, reaction learning, safety filtering, A/B evaluation, and avatar state visualization, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on dialogue logs, reaction metrics, facial/voice features, behavior candidates, and safety policies. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, SDK integration are leading, and integration tests, coverage 96.4% are already verified. Reinforcing test expansion is the next step to make the A-readiness substance explicit. The score is led by production readiness, SDK integration, with integration tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration tests, coverage 96.4%, production guard, structure, implementation depth, production readiness, SDK integration, coverage. Reinforcement: test expansion. Prioritize implementation depth, test evidence first. |
| Next focus | Avatar evolution UI is implemented; next focus is real session integration and safety-filter workflow validation. |
31. cooperative_edge_robotics_system
| Item | Content |
|---|---|
| Evaluation | A / 89.08 (Structure 14.30/15, Implementation 19.18/20, ProdReady 20.00/20, SDK 7.00/15, Testing 18.75/20, Coverage 9.85/10) |
| Product detail | A robotics platform that coordinates multiple edge robots on field networks and controls missions, state, failures, and redeployment. Intended users are factory and warehouse operators, robot control staff, field maintenance teams, and edge AI developers. It continuously ingests robot state, mission queues, maps, communication quality, sensor data, and fault events and provides cooperative mission assignment, health monitoring, control UI, fault recovery, and edge inference integration as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | factory and warehouse operators, robot control staff, field maintenance teams, and edge AI developers |
| Main inputs / integration data | robot state, mission queues, maps, communication quality, sensor data, and fault events |
| Core capabilities | cooperative mission assignment, health monitoring, control UI, fault recovery, and edge inference integration |
| Use case / value | The primary scenario is for factory and warehouse operators, robot control staff, field maintenance teams, and edge AI developers to review robot state, mission queues, maps, communication quality, sensor data, and fault events, use cooperative mission assignment, health monitoring, control UI, fault recovery, and edge inference integration, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on robot state, mission queues, maps, communication quality, sensor data, and fault events. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, coverage are leading, and integration tests, coverage 98.5% are already verified. Reinforcing SDK integration is the next step to make the A-readiness substance explicit. The score is led by production readiness, coverage, with integration tests, coverage 98.5%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration tests, coverage 98.5%, production guard, implementation depth, test evidence, structure, production readiness, coverage. Reinforcement: SDK integration. Prioritize SDK integration, test evidence first. |
| Next focus | Frontend is implemented; next focus is stronger SDK integration and higher coverage. |
32. autonomous_disaster_response_system
| Item | Content |
|---|---|
| Evaluation | A / 88.65 (Structure 14.30/15, Implementation 16.83/20, ProdReady 20.00/20, SDK 12.00/15, Testing 16.90/20, Coverage 8.62/10) |
| Product detail | A disaster response platform that combines field situation awareness, resource allocation, and robot/drone operation to support emergency decision-making. Intended users are municipal agencies, disaster headquarters, fire and rescue teams, field commanders, and robot operators. It continuously ingests damage reports, maps, weather, sensors, drone video, shelters, roads, and material inventories and provides damage estimation, mission assignment, route replanning, field risk monitoring, and response/audit logs as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | municipal agencies, disaster headquarters, fire and rescue teams, field commanders, and robot operators |
| Main inputs / integration data | damage reports, maps, weather, sensors, drone video, shelters, roads, and material inventories |
| Core capabilities | damage estimation, mission assignment, route replanning, field risk monitoring, and response/audit logs |
| Use case / value | The primary scenario is for municipal agencies, disaster headquarters, fire and rescue teams, field commanders, and robot operators to review damage reports, maps, weather, sensors, drone video, shelters, roads, and material inventories, use damage estimation, mission assignment, route replanning, field risk monitoring, and response/audit logs, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on damage reports, maps, weather, sensors, drone video, shelters, roads, and material inventories. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, structure are leading, and integration/performance tests, coverage 86.2% are already verified. Reinforcing SDK runtime probe is the next step to make the A-readiness substance explicit. The score is led by production readiness, structure, with integration/performance tests, coverage 86.2%, production gate already verified. Strengths: implemented UI, integration/performance tests, coverage 86.2%, production guard, implementation depth, structure, production readiness, SDK integration, test evidence, coverage. Reinforcement: SDK runtime probe. Prioritize SDK integration, implementation depth first. |
| Next focus | Disaster-response UI is implemented; next focus is real disaster-data integration and field-operation SLO validation. |
33. tidal_crowd_simulation
| Item | Content |
|---|---|
| Evaluation | A / 88.25 (Structure 13.50/15, Implementation 16.41/20, ProdReady 20.00/20, SDK 15.00/15, Testing 13.70/20, Coverage 9.64/10) |
| Product detail | A simulation product that combines crowd flow, tides, terrain, and evacuation routes to evaluate congestion and evacuation scenarios for coastal areas or event venues. Intended users are municipalities, disaster prevention teams, event operators, urban planners, and coastal facility managers. It continuously ingests crowd-flow data, tides, terrain, evacuation routes, facility capacity, and scenario conditions and provides congestion prediction, evacuation simulation, density heatmaps, and scenario comparison as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | municipalities, disaster prevention teams, event operators, urban planners, and coastal facility managers |
| Main inputs / integration data | crowd-flow data, tides, terrain, evacuation routes, facility capacity, and scenario conditions |
| Core capabilities | congestion prediction, evacuation simulation, density heatmaps, and scenario comparison |
| Use case / value | The primary scenario is for municipalities, disaster prevention teams, event operators, urban planners, and coastal facility managers to review crowd-flow data, tides, terrain, evacuation routes, facility capacity, and scenario conditions, use congestion prediction, evacuation simulation, density heatmaps, and scenario comparison, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on crowd-flow data, tides, terrain, evacuation routes, facility capacity, and scenario conditions. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, SDK integration are leading, and integration tests, coverage 96.4% are already verified. Reinforcing test expansion is the next step to make the A-readiness substance explicit. The score is led by production readiness, SDK integration, with integration tests, coverage 96.4%, production gate already verified. Strengths: implemented UI, SDK runtime probe, integration tests, coverage 96.4%, production guard, implementation depth, structure, production readiness, SDK integration, coverage. Reinforcement: test expansion. Prioritize test evidence, implementation depth first. |
| Next focus | Crowd-simulation UI is implemented; next focus is real tidal-data integration and evacuation-scenario workflow validation. |
34. space_debris_management
| Item | Content |
|---|---|
| Evaluation | A / 87.23 (Structure 15.00/15, Implementation 14.15/20, ProdReady 20.00/20, SDK 15.00/15, Testing 17.00/20, Coverage 6.08/10) |
| Product detail | A space operations product that integrates orbit information, observations, and close-approach risk to support space debris tracking and avoidance planning. Intended users are satellite operators, space agencies, orbit analysts, and mission control teams. It continuously ingests orbital elements, observation data, satellite state, close-approach predictions, and avoidance constraints and provides debris tracking, collision risk evaluation, avoidance planning, alerts, and orbit visualization as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | satellite operators, space agencies, orbit analysts, and mission control teams |
| Main inputs / integration data | orbital elements, observation data, satellite state, close-approach predictions, and avoidance constraints |
| Core capabilities | debris tracking, collision risk evaluation, avoidance planning, alerts, and orbit visualization |
| Use case / value | The primary scenario is for satellite operators, space agencies, orbit analysts, and mission control teams to review orbital elements, observation data, satellite state, close-approach predictions, and avoidance constraints, use debris tracking, collision risk evaluation, avoidance planning, alerts, and orbit visualization, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on orbital elements, observation data, satellite state, close-approach predictions, and avoidance constraints. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, SDK integration are leading, and performance tests, production gate are already verified. Reinforcing coverage 60.8% is the next step to make the A-readiness substance explicit. The score is led by production readiness, SDK integration, with performance tests, production gate, SDK runtime verification already verified. Strengths: implemented UI, SDK runtime probe, performance tests, production guard, structure, implementation depth, production readiness, SDK integration, test evidence. Reinforcement: coverage 60.8%. Prioritize coverage, implementation depth first. |
| Next focus | SDK integration is strong; next focus is coverage, implementation depth, and orbit analysis UI. |
35. project_vr
| Item | Content |
|---|---|
| Evaluation | A / 86.94 (Structure 15.00/15, Implementation 18.92/20, ProdReady 18.70/20, SDK 9.50/15, Testing 19.50/20, Coverage 5.32/10) |
| Product detail | A product that integrates VR spaces, interaction events, experience state, and operational APIs to support immersive application execution and monitoring. Intended users are VR developers, event operators, education/training teams, and experience designers. It continuously ingests VR scenes, user operations, device state, experience logs, and operational API settings and provides VR experience control, state monitoring, API integration, operation logs, and scenario execution as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | VR developers, event operators, education/training teams, and experience designers |
| Main inputs / integration data | VR scenes, user operations, device state, experience logs, and operational API settings |
| Core capabilities | VR experience control, state monitoring, API integration, operation logs, and scenario execution |
| Use case / value | The primary scenario is for VR developers, event operators, education/training teams, and experience designers to review VR scenes, user operations, device state, experience logs, and operational API settings, use VR experience control, state monitoring, API integration, operation logs, and scenario execution, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on VR scenes, user operations, device state, experience logs, and operational API settings. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | structure, test evidence are leading, and integration/performance tests, production gate are already verified. Reinforcing coverage 53.2%, SDK integration is the next step to make the A-readiness substance explicit. The score is led by structure, test evidence, with integration/performance tests, production gate, SDK runtime verification already verified. Strengths: implemented UI, SDK runtime probe, integration/performance tests, production guard, implementation depth, test evidence, structure, production readiness. Reinforcement: coverage 53.2%, SDK integration. Prioritize coverage, SDK integration first. |
| Next focus | Implementation depth and tests are strong; next focus is SDK and coverage improvement. |
36. neuro_ecosystem
| Item | Content |
|---|---|
| Evaluation | A / 86.81 (Structure 14.30/15, Implementation 18.00/20, ProdReady 20.00/20, SDK 7.50/15, Testing 18.50/20, Coverage 8.51/10) |
| Product detail | A research platform that simulates interactions, resources, and adaptation in distributed agents and artificial ecosystem evolution. Intended users are complex-systems researchers, AI researchers, simulation developers, and education/exhibition teams. It continuously ingests agent settings, environmental conditions, resource distributions, interaction rules, and observation logs and provides evolution simulation, interaction analysis, environment-change experiments, visualization, and result comparison as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | complex-systems researchers, AI researchers, simulation developers, and education/exhibition teams |
| Main inputs / integration data | agent settings, environmental conditions, resource distributions, interaction rules, and observation logs |
| Core capabilities | evolution simulation, interaction analysis, environment-change experiments, visualization, and result comparison |
| Use case / value | The primary scenario is for complex-systems researchers, AI researchers, simulation developers, and education/exhibition teams to review agent settings, environmental conditions, resource distributions, interaction rules, and observation logs, use evolution simulation, interaction analysis, environment-change experiments, visualization, and result comparison, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on agent settings, environmental conditions, resource distributions, interaction rules, and observation logs. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | production readiness, structure are leading, and integration tests, coverage 85.1% are already verified. Reinforcing SDK integration is the next step to make the A-readiness substance explicit. The score is led by production readiness, structure, with integration tests, coverage 85.1%, production gate already verified. Strengths: implemented UI, integration tests, coverage 85.1%, production guard, implementation depth, test evidence, structure, production readiness, coverage. Reinforcement: SDK integration. Prioritize SDK integration, coverage first. |
| Next focus | Ecosystem evolution UI is implemented; next focus is real simulation integration and visualization workflow validation. |
37. sports_strategy_evolution_system
| Item | Content |
|---|---|
| Evaluation | B / 82.09 (Structure 14.30/15, Implementation 14.32/20, ProdReady 13.88/20, SDK 15.00/15, Testing 16.05/20, Coverage 8.54/10) |
| Product detail | A sports strategy support product that uses player data, match state, and tactical candidates to compare strategies and risks through evolutionary search. Intended users are managers, coaches, analysts, player development teams, and sports data providers. It continuously ingests player abilities, match logs, opponent tendencies, tactical candidates, condition data, and video metadata and provides tactical search, lineup suggestions, opponent analysis, scenario comparison, and strategy reports as an end-to-end workflow. It is maintained as an operational product, not just a demo, with EvoSpikeNet SDK integration, operations monitoring, audit evidence, UI, and user procedures so decisions and execution results can be traced in real use. |
| Intended users | managers, coaches, analysts, player development teams, and sports data providers |
| Main inputs / integration data | player abilities, match logs, opponent tendencies, tactical candidates, condition data, and video metadata |
| Core capabilities | tactical search, lineup suggestions, opponent analysis, scenario comparison, and strategy reports |
| Use case / value | The primary scenario is for managers, coaches, analysts, player development teams, and sports data providers to review player abilities, match logs, opponent tendencies, tactical candidates, condition data, and video metadata, use tactical search, lineup suggestions, opponent analysis, scenario comparison, and strategy reports, and close the workflow from planning and execution through monitoring, analysis, and reporting. This README provides the overview; screen design, settings, data acquisition, monitoring, functional trace, execution, and analysis details are managed in each product's implementation_plan.md. |
| Data acquisition / integration policy | Inputs center on player abilities, match logs, opponent tendencies, tactical candidates, condition data, and video metadata. External APIs, sensors, logs, files, and user actions should be connected according to product characteristics. For real-data integration, define the source, update frequency, missing-data handling, audit logs, and strict-mode stub prohibition. Tests should cover not only successful paths but also missing data, delays, authentication failures, retries, and fallback rejection. |
| Screen / operations perspective | Frontend status is Implemented. Overview, Settings, Data Acquisition, Monitoring, Functional Trace, Execution, Analysis, and Audit/Admin are treated as the standard operational screen set so settings, acquisition, monitoring, trace, execution, analysis, and audit evidence can be followed. |
| Frontend | Implemented |
| Implementation evaluation | SDK integration, structure provide a base and coverage 85.4%, production gate are visible, but strengthening production guard is needed to reach grade A. The score is led by SDK integration, structure, with coverage 85.4%, production gate, SDK runtime verification already verified. Strengths: implemented UI, SDK runtime probe, coverage 85.4%, structure, implementation depth, SDK integration, test evidence, coverage. Reinforcement: production guard. Prioritize production readiness, implementation depth first. |
| Next focus | Strategy evolution UI is implemented; next focus is real match-data integration and tactical-evaluation workflow validation. |