# Platform embed packet manifest

Version: public v1
Audience: Product and platform teams evaluating G‑14 as an embedded control plane

## Summary
Use this manifest to review how G‑14 fits inside your product or workflow.

Route: Platform review (/platform)
Docs: https://docs.g14.ai/use-cases/embedded-ai-in-products
Blueprint: Embedded product control plane (https://docs.g14.ai/reference-architectures/embedded-product-control-plane)

## Inspection burden
- Clarify whether G‑14 belongs inside the host product as a real control plane instead of a wrapper layer.
- Make the integration boundary and operator/runtime split visible before a bespoke architecture review opens.
- Reduce the next move to an architecture-first briefing, focused integration review, or a clear defer.

## Stack anchors
- Atlas carries bounded execution and mission state inside the host product without leaving the product outside the control boundary.
- Apollo exposes operator review and command for product teams without weakening the boundary.
- Castor, Lamina, and Covalence preserve authority, verified runtime state, and blast-radius awareness.

## Briefing fit
- Use the architecture-first briefing when the unresolved question is still where G‑14 sits in the host product and how the control plane boundary is enforced.
- Move into focused integration review when the packet already made the deployment pattern and published material clear enough for a narrower technical decision.
- Move into strategic collaboration only if the packet clearly shows the platform-fit question is larger than one integration review.

## Public-safe artifacts
- Public object model and integration sequence
- Authority, execution, receipts, and release in the host product
- Integration model and review path
- Adoption model from entry product to standard

## Custody checks
- Packet stays attached to the platform question instead of widening into generic diligence.
- Blueprint pairing remains explicit before a briefing opens.
- The next move is architecture-first and named.

## Decision outcomes
- Proceed to architecture-first briefing
  Choose this when the packet narrowed the question to integration topology, operator split, or deployment shape that still needs a live technical session.
- Proceed to focused integration review
  Choose this when the packet already made the standardization case clear enough that a smaller implementation-focused next step is justified.
- Reassess or defer
  Choose this when the packet showed the platform question is still too broad or premature for the current discussion.

## Next moves
- Architecture-first briefing
- Focused integration review
- Explicit defer or decline

## Protected boundary
- No proprietary implementation detail
- No private integration heuristics
- No unreleased module behavior