Skip to content
Foyre Foyre

Intake workflow

Submit your first AI workload request

Fill out Foyre’s intake form, submit the request, review the generated risk score and reasons, and understand when to create a validation sandbox before marking the request ready for review.

Difficulty
Beginner
Time
5-10 minutes
Category
Request intake
Tags
AI intake, risk review

This tutorial walks through the requester side of Foyre. You will create an AI workload request, submit it for classification, inspect the risk result, and learn where validation environments fit into the workflow.

Important

Do not mark a request ready for review until you have deployed the application into its validation sandbox, if your organization expects hands-on validation. Reviewers should be looking at a running workload, not just a submitted form.

Before you start

You need:

  • A running Foyre instance
  • An account with the requester role, or an admin account for testing
  • Basic information about the AI workload you want to submit
  • A connected host Kubernetes cluster if you want to create an isolated validation sandbox

You can submit a request without validation infrastructure. The Create isolated cluster button appears after host-cluster setup is complete.

1. Create a new request

Sign in to Foyre and open the request intake area. Create a new AI application request.

The request starts as a draft. You can fill in the form, save progress, and come back before submitting.

2. Fill out the intake form

Foyre asks the questions platform, IT, security, and architecture teams usually need before approving an AI workload. The form is intentionally specific to AI systems.

Expect to provide information such as:

  • Application name, owner, and team
  • Target environment, such as development, validation, or production
  • Workload type, such as chatbot, RAG service, inference API, agent, or training job
  • Data sensitivity and classification
  • Whether the workload uses enterprise documents, vector databases, or external model APIs
  • Agent behavior, GPU requirements, internet egress, and deployment timeline

Tip

Conditional fields keep the form shorter. For example, if your workload does not use a vector database, Foyre should not ask follow-up questions about vector indexing.

3. Submit the request

When the form is complete, click Submit.

Foyre validates required fields and moves the request from draft to submitted. Once submitted, the request becomes visible to reviewers, architects, and admins according to their roles.

4. Review the risk score and reasons

After submission, Foyre classifies the request using deterministic rules. The result is a risk rating such as low, medium, high, or unknown.

The risk result should include human-readable reasons so reviewers can see why Foyre classified the request the way it did. Examples include external model API use with regulated data, agents that take actions on behalf of a user, or incomplete answers that require follow-up.

Note

The risk score is not generated by an AI model. It comes from deterministic rules, which makes the result easier to explain and adjust over time.

5. Create an isolated validation sandbox

If validation environments are configured, the submitted request can show a Create isolated cluster button.

Clicking it asks Foyre to provision a dedicated vcluster on the connected host Kubernetes cluster. Foyre returns a scoped kubeconfig for that sandbox. The requester uses that kubeconfig with kubectl or Helm to deploy the application into the validation environment.

Warning

Do not click Mark ready for review immediately after creating the sandbox. First deploy the application into the validation environment and verify it is running. The point of the sandbox is to give reviewers something real to inspect.

6. Mark the request ready for review

After the application is deployed into the validation sandbox, return to the request and click Mark ready for review.

This tells reviewers that the request is no longer just intake data. It has a deployed workload they can inspect, discuss, approve, reject, or send back for changes.

Reviewers and admins can then look at the form answers, the risk score and reasons, comments, request history, and any validation environment that has been provisioned.

What you should see

  • A submitted AI workload request
  • A deterministic risk rating with one or more risk reasons
  • A request history entry showing the submission event
  • If validation is configured, a path to create an isolated vcluster sandbox
  • After deployment, a request marked ready for reviewer action

Next steps