Vercel Logo

Prove it is ready

Run the application and the eve agent from course-work. Follow one vendor request through submission, policy routing, and a human decision. Use a request that costs exactly $50,000, handles restricted data, and begins with one missing field.

Run the whole path

  1. Ask the agent to create the request without the business purpose. It should ask for the missing field instead of guessing.
  2. Supply the purpose. The agent should summarize the four fields and pause before calling request_vendor_review.
  3. Decline the tool. Confirm that the application has no new request.
  4. Try again and approve the tool once. Confirm that exactly one request appears.
  5. Inspect the stored route. Procurement and Security should both be required: the request meets the policy's cost threshold and involves restricted data.
  6. Inspect the model assessment separately. It may suggest risk and missing information; it should not contain a vendor decision.
  7. Confirm the workflow waits at waiting_for_review.
  8. Attempt a decision as an employee without the required reviewer groups. The API should deny it.
  9. Approve with the course demo identity assigned to both reviewer groups. The record should name the reviewer and preserve the request, policy, model, and decision evidence. A real process that requires separate decisions needs two approval records, not this lab shortcut.
  10. Send the same decision again, then the opposite decision. The first repeat should return the existing result; the conflict should fail visibly.

Inspect the evidence

Inspect the completed request in the application and its database record. Locate:

  • The request creator and original fields
  • Policy route and policy version
  • Model and assessment version
  • Workflow run identifier and final status
  • Verified reviewer and timestamp

Then gather the supporting results from their sources:

  • Evaluation output and docs/model-record.md for the same policy boundary
  • AI Gateway usage for model cost; if you cannot isolate this call, record the reporting period and available totals rather than inventing a per-request figure
  • docs/readiness.md for project-level access and security checks
  • Organization-wide findings in the Security Dashboard, when available

Now open the three course documents on complete and compare them with yours:

Update docs/readiness.md with the results of this run. Keep enterprise controls demonstrated or planned unless you configured and tested them.

Make the rollout decision

Choose one outcome and write the reason:

  1. Keep as a private prototype
  2. Continue a small team test
  3. Promote to a reviewed company application
  4. Retire it

A small team test may be the limit of your course environment if employee SSO, managed builder identity, or verified enterprise reviewer identity remains unimplemented. Name any missing control that blocks broader access and who will implement it.

Write the decision and its reason in docs/operating-report.md, then make the final course commit:

git add docs
git commit -m "docs: record rollout decision"
git push -u origin course-work

Final architecture

Use this diagram to explain the intended architecture. For each connection, point to your implementation, a demonstration you inspected, or a planned control in docs/readiness.md.

managed builders ──→ Git and protected deployments
employees ─────────→ company identity ──→ Vendor Review
eve intake agent ── approval gate ──────→ Vendor Review request API
Vendor Review ─────→ Vercel Connect ─────→ scoped system access
       │
       ├─ deterministic policy
       ├─ structured model assessment through AI Gateway
       ├─ durable workflow and verified human decision
       └─ evidence: records, evaluations, observability, cost

when requirements change:
  broader agent autonomy → separate tools, memory, and approval review
  untrusted code → Sandbox
  private infrastructure or account ownership → a dedicated runtime review

Summary

You have traced a vendor request through agent intake, deterministic policy, model assessment, and human review. The rollout decision records what that run proved, what your operating report shows, and which unfinished controls still limit access.

Check your work

Using the final request and its related records, explain who created it, why each reviewer was required, what the model contributed, who decided, and what happened when the same action was repeated. Then identify the deployment that would receive the next change and the owner responsible for it.

Was this helpful?

supported.