How PSL Works?
PSL is a linchpin for constructing robust and dynamic GenAI applications. Let's dive into how PSL functions.
What goes inside a PSL File?
A PSL file includes both configurational as well as workflow related setups.
Configurational Elements
While they are optional for simpler applications, the following elements can be incorporated when necessitated by the workflow::
Metadata: Details like the author's name, version, and more.
Defaults: Default models and the associated parameters required for the workflow.
Imports: Describes any sub-workflows that have been integrated.
Input and Output schemas: Variables scopes and dependencies, if needed.
Workflow Definitions
A valid PSL file also includes task definitions which define the workflow of the GenAI app. There are several types of tasks that can be used in the workflow but here are the three main ones:
Ask: Ask the app user for input.
Display: Display content to the user. Content could be
text,audio,markdown,video, etc.Prompt: Use an AI model or an in-house primitive to produce an output.
An Ask or a Prompt task creates a global variable that is easily accessible. User inputs are saved and referred to using the {{input.ask_task_name}} syntax, while the outputs from AI models are stored and recalled with {{response.model_task_name}}. This structure not only keeps the code readable but also allows for dynamic interactions, where previous responses and inputs can be employed to inform future actions, creating a truly interactive experience for the user.
A task may use user input and response variables defined before it. A task may also be conditional upon these being available.
A Prompt task may also run a sub-workflow which has been defined in the imports. A sub-workflow may be used for various tasks, for example:
User input based retries
Running a component defined in another PSL file
Each task could be conditional based on existing user inputs and available responses.
PSL Runtime: How is a PSL file executed?
When a user interacts with a GenAI app specified in a PSL file, the PSL runtime starts executing the workflow line-by-line. At a given point in time, it looks at the set of remaining tasks that have not been executed yet and determines the largest subset, depending on available workers, that can be executed in parallel keeping all dependencies, sub-workflows and conditionals in mind, and executes that batch of tasks in parallel. In particular, the runtime ensures the following:
If Task A comes before Task B and both of them change the state of the end-user UI then Task B is not executed in a earlier batch than that of Task A.
If Task B uses the variable created by Task A then Task A is executed in an earlier batch to ensure that the variable is available for Task B.
While executing the tasks, the runtime emits events that gets mapped to a UI experience for the end user. For example, if runtime emits a FormRequestEvent, the end-user sees a form on the UI, or if runtime emits a Display, the corresponding content is displayed to the user in the correct format.
Last updated
