[Feature Request]: Extensible intelligent inspection and observability foundation for MatrixOne Cloud

## Is your feature request related to a problem?

MatrixOne already exposes logs, metrics, runtime signals, and diagnostic data across different components and platforms, but these capabilities are not yet organized as a coherent observability and inspection product.

The current experience relies heavily on manual investigation and platform-specific knowledge. Observability data may have inconsistent semantics, incomplete context, or limited correlation, while diagnostic knowledge is difficult to package, reuse, customize, and deliver to users.

MatrixOne Cloud needs an official intelligent inspection product built on well-designed observability foundations, rather than a collection of dashboards, alerts, or internal scripts.

## Describe the feature you'd like

Deliver an extensible **Intelligent Inspection** product in MatrixOne Cloud, backed by standardized logs, metrics, events, topology, and diagnostic evidence.

The product should help users understand cluster health, detect risks, investigate incidents, and obtain explainable recommendations. It should support both MatrixOne-provided capabilities and tenant-specific customization.

### 1. Observability foundation

Provide a governed and reusable foundation for logs, metrics, events, runtime state, topology, configuration, and diagnostic artifacts.

The foundation should provide:

- Clear and consistent semantics, naming, ownership, units, lifecycle, and documentation.
- Reliable correlation across components, cluster resources, workloads, and time ranges.
- Well-designed logs and metrics with appropriate quality, cardinality, cost, privacy, and retention controls.
- A discoverable catalog that can be consumed by developers, Cloud services, inspection capabilities, and AI agents.
- Stable and permission-aware access to the evidence required for diagnosis.

### 2. Intelligent inspection as a Cloud product

MatrixOne Cloud should provide a formal inspection experience with:

- Manual, scheduled, and event-triggered inspections.
- Built-in inspection packages for common health, reliability, performance, and resource risks.
- Configurable scope, policies, schedules, notification behavior, and maintenance windows.
- Inspection history, findings, evidence, recommendations, and operational follow-up.
- APIs and integrations for automation and external operational workflows.

The product should work as an ongoing health and risk management capability, not only as a post-incident troubleshooting tool.

### 3. Rules and customization

The inspection system should support both built-in and user-defined rules.

Users should be able to customize inspection behavior for different clusters, workloads, deployment models, and operational requirements without modifying MatrixOne source code. Rules and configurations should be versioned, testable, reusable, and safely managed.

### 4. Extensible inspection Skills

Provide a standard Skill model for packaging reusable diagnostic and inspection knowledge.

The platform should support:

- MatrixOne-provided, partner-provided, and tenant-private Skills.
- Clear contracts for required evidence, permissions, execution limits, and structured results.
- Skill lifecycle management, including validation, versioning, compatibility, rollout, and rollback.
- Safe isolation so that extensions cannot bypass tenant, data, or platform boundaries.

The same inspection capability should be reusable across supported environments through configuration rather than environment-specific implementations.

### 5. Model and AI extensibility

AI should enhance correlation, explanation, summarization, and diagnostic reasoning while remaining grounded in observable evidence.

The platform should support:

- A MatrixOne-provided default model experience.
- User-provided models and model endpoints where appropriate.
- Tenant-level control over model selection, data access, cost, and usage policies.
- Safe credential management, data minimization, privacy controls, and auditability.
- Graceful operation when a model is unavailable or disabled.

Model output must not be treated as confirmed fact without supporting evidence. Deterministic rules and non-AI inspection capabilities should remain independently usable.

### 6. Explainable findings and operational workflow

Inspection results should be understandable and actionable. A finding should communicate:

- What was detected and why it matters.
- The affected scope and time range.
- Supporting evidence, confidence, and known evidence gaps.
- Recommended next steps and relevant operational guidance.

The product should support the lifecycle from detection and ownership through investigation, resolution, feedback, and retrospective analysis.

### 7. Product governance

The capability must meet Cloud product requirements for:

- Multi-tenant isolation and role-based access control.
- Sensitive-data protection and configurable data boundaries.
- Auditability of inspections, rules, Skills, models, and configuration changes.
- Bounded resource usage, observability cost, and model cost.
- Compatibility, availability, and safe evolution across MatrixOne versions.

## Expected outcome

- MatrixOne Cloud provides an official, user-facing intelligent inspection product.
- Logs and metrics become reliable product foundations rather than isolated instrumentation.
- Common inspections are available out of the box while customers can customize rules, Skills, schedules, and models.
- Findings are evidence-based, explainable, traceable, and operationally actionable.
- Diagnostic knowledge can evolve independently through governed rules and Skills.
- The foundation can support future capabilities such as assisted remediation and broader AI operations without requiring them in the initial delivery.

## Scope principles

- Cloud is the primary delivery surface, while foundational capabilities should remain reusable across supported MatrixOne deployment modes.
- The initial goal is inspection and decision support, not unattended remediation.
- This work should evolve and reuse the existing observability ecosystem instead of requiring a complete platform replacement.
- More telemetry is not automatically better; data quality, semantics, evidence, safety, and cost are first-class requirements.

## Related work

- #24222
- #26185