# Technical evaluation packet manifest

Version: public v1
Audience: Engineering, platform, architecture, and security teams

## Summary
Use this manifest to review the technical packet for entry-product proof, runtime evidence, integration boundary, and the core control contract.

Route: Technical diligence (/diligence)
Docs: https://docs.g14.ai/evaluate/technical-due-diligence-checklist
Blueprint: Embedded product control plane (https://docs.g14.ai/reference-architectures/embedded-product-control-plane)

## Inspection burden
- Determine whether the control contract meets your engineering standards.
- Review how Apollo, Atlas, and Castor work together before access or deeper diligence.
- Reduce the next decision to a briefing, hands-on access, or a clear no-go.

## Stack anchors
- Atlas turns intent into bounded work instead of unconstrained automation.
- Apollo keeps human review and command inside the governed review path.
- Castor, Lamina, and release control keep authority, evidence, and closure explicit.

## Briefing fit
- Use the standard technical briefing if the remaining question is still architecture or live execution.
- Move straight to hands-on access only if the packet already answered enough to justify hands-on evaluation.
- Move into a broader platform discussion only if the unresolved question is clearly about platform fit or deployment shape.

## Public-safe artifacts
- Control loop and category thesis
- Authority, execution, evidence, and release checkpoints
- Integration model and SDK posture
- Nearest blueprint for product, operations, or internal workflow fit

## Custody checks
- Scoped to the exact unresolved question before issue.
- Scoped to the evaluating team instead of becoming a generic review deck.
- Points to a bounded briefing or decision instead of indefinite follow-up.

## Decision outcomes
- Proceed to technical briefing
  Choose this when the packet narrowed the question to architecture, trust model, or live execution that still needs one live review session.
- Proceed to hands-on access
  Choose this when the packet already answered enough that hands-on product or platform evaluation is the smallest serious next move.
- Decline or defer
  Choose this when the packet revealed that the timing, scope, or fit is wrong and more follow-up would only create confusion.

## Next moves
- Technical briefing
- Hands-on access request
- Explicit decline or defer

## Protected boundary
- No protected implementation thresholds
- No private deployment runbooks
- No proprietary mechanism detail