manifest-structure

To document product architecture in a structured manifest, define canonical top-level fields for project details, users, frontends, services, databases, integrations, agents, shared types, observability, and security. This standardized format captures the entire system design in one document for stakeholder alignment.

A canonical system manifest provides a standardized format to capture a product's architecture, ensuring consistent representation of components like apps, agents, services, and databases. It facilitates downstream tooling, validation, and cross-team communication for architecture design.

Structure a manifest for multiple services and integrations by filling in top-level project details, followed by enumerated lists of frontends, services, databases, integrations, and agents. Add shared types, observability, security, and deployment sections using valid enumerated types.

You need a canonical manifest when starting a new product to align stakeholders on architecture boundaries and technology choices. It ensures consistent documentation of components like frontends, services, databases, and agents, enabling downstream validation and tooling.

Yes, the structured manifest format explicitly supports systems with agents and observability components. It includes dedicated top-level fields for agents, shared types, observability, and security, allowing you to document these components alongside frontends, services, and databases.

The standardized architecture manifest requires predefined enumerated types and structured patterns for valid values, meaning you must conform to its specific top-level fields like project, users, frontends, services, databases, and integrations rather than using freeform documentation.