# Proposal Assessment Path

## Purpose

The proposal assessment path defines how the AI Capability Playbook can review a submitted AI use case, architecture submission, assistant concept, workflow, or capability proposal against approved package criteria.

This path is not an approval engine. It produces source-grounded review assistance for human reviewers.

Generated assessment outputs are derivatives. They do not become authoritative source evidence by default.

## Inputs

A proposal should provide as much of the following as possible:

- intended business outcome
- user group and workflow
- proposed AI behavior
- sources and source authority
- data classes and data boundaries
- deterministic steps and probabilistic steps
- expected outputs
- evaluation approach
- human review model
- telemetry and observability plan
- sustainment owner
- risk and governance posture
- tool, data, workflow, and production approval status

When the proposal does not include enough information for a dimension, the finding class should be `missing evidence`.

## Finding Classes

| Class | Meaning |
|---|---|
| `pass` | The proposal provides enough evidence for the criterion at the requested review depth. |
| `concern` | The proposal partially addresses the criterion but leaves meaningful uncertainty, weakness, or follow-up. |
| `blocker` | The proposal conflicts with playbook guidance, approval boundary, source boundary, or safe operating posture. |
| `missing evidence` | The proposal does not provide enough information to assess the criterion. |
| `not covered` | The approved package does not contain enough guidance for this criterion. |

## Assessment Dimensions

| Dimension | What To Assess | Source-Grounded Question |
|---|---|---|
| Intent and outcome clarity | Whether the proposal names the problem, user, desired outcome, and success signal. | Does the proposal define the outcome clearly enough to judge capability readiness? |
| Source authority | Whether the sources are named, ranked, current, and reviewable. | What source is authoritative, and what must not be inferred from silence? |
| Data boundary | Whether data classes, allowed use, retention, and sharing limits are explicit. | Does the proposal separate approved data use from unsupported assumptions? |
| Workflow fit | Whether AI is appropriate for the work and the workflow is understood. | Is this a use case for no AI, deterministic automation, AI assistance, or governed capability? |
| Deterministic versus probabilistic work | Whether stable deterministic steps stay deterministic and model judgment is bounded. | Which steps require model interpretation, and which should remain procedural or rule-based? |
| Evaluation readiness | Whether fixtures, rubrics, negative controls, and regression checks are defined. | How will the team know the output is valid, not merely fluent? |
| Human review model | Whether human accountability, reviewer action, and escalation are clear. | Who reviews, decides, overrides, and remains accountable? |
| Telemetry and observability | Whether value, quality, failure, drift, and usage signals are inspectable. | What evidence shows the capability works, degrades, or should stop? |
| Sustainment and ownership | Whether maintenance, model/source changes, support, and review cadence are owned. | Who keeps the capability current after the demo? |
| Risk and governance posture | Whether risk, approval path, policy sensitivity, and residual concerns are explicit. | What governance route or stop condition applies? |
| Tool, data, workflow, and production approval boundary | Whether the proposal avoids treating access as approval. | Does the proposal separate tool availability from use-case, data, workflow, and production approval? |

## Assessment Output Contract

Each finding should include:

- finding class
- assessment dimension
- concise finding text
- proposal evidence used
- missing evidence, if any
- playbook criterion or concept
- cited artifact ID, section ID, source path, or context-pack reference
- recommended reviewer action
- approval-boundary note when relevant

If a cited source is not available in the approved package structure, the assessment should state that the criterion is not covered or that citation support is missing.

## Review-Output Options

The assessment path may generate downstream review artifacts:

- review memo
- email draft back to requester
- approval-with-conditions note
- return-for-more-information checklist
- risk/governance summary
- HTML review packet
- DOCX review packet where supported by existing exports

These outputs should include their source basis and should be labeled as generated derivatives. They should not replace canonical playbook source, approval records, human review, validation receipts, or governance decisions.

## Refusal And Boundary Behavior

Use refusal patterns when the source package or proposal evidence is insufficient:

```text
Not found in the approved playbook package.
```

```text
The playbook provides guidance, but it does not approve this tool, data class, workflow, production use, or company policy.
```

```text
The submitted proposal lacks enough evidence to assess this criterion.
```

The assessment should not answer from model memory when the approved package is silent. It should not infer approval from tool access, source availability, package publication, or generated output.

## MVP Retrieval Posture

The MVP should use approved package structure before adding retrieval infrastructure:

- artifact manifest
- source map
- section IDs
- source paths
- canonical titles
- context-pack artifacts, sections, claims, grounding rules, and hashes
- claim and source-boundary fields
- validation receipts

The following stay deferred:

- database or graph backend
- vector store
- hosted retrieval service
- embedding-provider upgrade
- connector ingestion
- durable memory
- provider/model execution path
- enterprise workflow integration

## Relationship To Semantic Explainer

The semantic explainer defines the Find, Explain, and Assess modes. This note defines the Assess mode in enough detail to guide future implementation tickets without creating runtime behavior in this issue.