Vercel Logo

Prove it is ready

The capstone is one complete vendor request, not another checklist. Run the application and the eve agent from course-work. Use a vendor 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 because written policy owns the threshold and restricted-data rules.
  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.

The happy path ends with a boring success: one request, one workflow, one authorized decision, and enough evidence to explain each step. Boring is excellent here.

Inspect the evidence

Open the completed request and locate:

  • The request creator and original fields
  • Policy route and policy version
  • Model and assessment version
  • Workflow run and final status
  • Verified reviewer and timestamp
  • The evaluation result for the same policy boundary
  • Gateway usage and cost for the model call
  • Project-level security checks and, when available, the organization-wide findings in the Security Dashboard

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

Update docs/readiness.md only where the run produced new evidence. Keep enterprise controls demonstrated or planned unless you actually configured them. “Understood” is still not a control state.

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

The course environment will commonly end at a small team test because employee SSO, managed builder identity, or verified enterprise reviewer identity may remain demonstrated rather than implemented. That is an honest result.

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

The architecture is one path, not one permission. It lets builders deliver through organizational controls, lets employees reach the application through an access policy, and gives the application only the data and actions its job requires. More people can build without losing track of who owns each application, what it can reach, or what it costs.

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

Vercel provides one governed path from source code to a protected application: Enterprise Managed Users for builder lifecycle, Passport for employee identity, Vercel Connect for scoped system access, AI Gateway to govern model access and spend, durable execution, and auditable evidence. The application’s requirements determine which controls it needs.

The goal is not to claim that every control is complete. It is to make the rollout decision from evidence, identify what remains, and give each gap an owner.

Check your work

From the final request alone, 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 point to the deployment and owner that would handle the next change. If every answer has evidence, the course has done its job.

Was this helpful?

supported.