# Pascal for people and AI agents Source: https://www.trypascal.io/for-agents Understand Pascal’s AI operating system: business context, agent tools, approvals, example workflows, and developer resources in one reference. ## What is Pascal? Pascal is an AI operating system for companies. It connects business data and tools, gives them meaning through an ontology, and lets people and agents research, decide, build, and act through shared Tasks, Workrooms, and applications. - [Explore the platform](https://www.trypascal.io/platform) ## How do agents understand the business? Ontology connects business objects such as customers, shipments, and assets with their relationships and permitted actions. Dynamic Context assembles relevant sources for a task. Context Graph connects work, evidence, decisions, and outcomes so people can trace the basis of a result. - [Ontology](https://www.trypascal.io/platform/ontology) - [Dynamic Context](https://www.trypascal.io/platform/dynamic-context) - [Context Graph](https://www.trypascal.io/platform/context-graph) ## How can AI agents use company tools? Pascal connects existing business systems through integrations and exposes selected capabilities through MCP servers. Agents work with shared context in Tasks and Workrooms. Tool access depends on the workspace, connected systems, permissions, and required approvals. - [Agents](https://www.trypascal.io/platform/agents) - [MCP Servers](https://www.trypascal.io/platform/mcp-servers) - [Integrations](https://www.trypascal.io/platform/integrations) - [Workrooms](https://www.trypascal.io/platform/workrooms) ## Who controls what an agent can do? People set who can see data, use tools, and approve changes. Governance applies permissions and required approvals to actions. A proposal, an approved action, and a verified outcome are different states; a generated recommendation does not establish that a business change happened. - [Governance](https://www.trypascal.io/platform/governance) ## How do developers build on Pascal? Pascal Framework composes agents, workflows, and applications around business data. Developer resources cover typed APIs, TypeScript and Python SDKs, and project-local bindings. Projects keep their local bindings; production releases and business effects remain subject to review and permissions. - [Pascal Framework](https://www.trypascal.io/developers) - [Developer Platform](https://www.trypascal.io/platform/developer-platform) ## Which workflows does the website demonstrate? The website demonstrates logistics disruption response, private-equity deal readiness, customer renewal work, and building internal operational software. - [Explore the example workflows](https://www.trypascal.io/solutions) ## How can a team evaluate Pascal? Start with a workflow, its source systems, and the decisions that need human review. Contact Pascal to discuss access, deployment requirements, and pricing. The website’s contact form prepares an email draft for you to review and send; completing the form does not submit an inquiry. - [Contact Pascal](https://www.trypascal.io/contact) ## Developer documentation [Request docs access](https://www.trypascal.io/contact?intent=developer-docs) ## Machine-readable resources - [Content index](https://www.trypascal.io/llms.txt) - [Combined product and solution reference](https://www.trypascal.io/llms-full.txt) --- # Pascal Agent Observability Source: https://www.trypascal.io/platform/observability Understand what happened. Follow it to the outcome. Find agent failures, inspect the calls behind them, and connect the evidence to the work. Bring quality, timing, and usage into the same investigation. ## Capabilities ### Find the reported failure Search captured phrases and filter observations by source, trace, status, model, or tool. Save a view to return to the same investigation. ### Inspect model and tool calls Follow observed spans and inspect permitted inputs, outputs, errors, and timing. See where capture or coverage is incomplete. ### Understand time and usage Inspect recorded durations and token usage. Keep unavailable measurements visible when evaluating the work’s cost and performance. ### Monitor quality in use Score selected observations with versioned evaluators and budget controls. Review monitor windows, alerts, and missing-data states. ### Take the next step Open an investigation Task or prepare a dataset from selected evidence. Preserve the source behind the case as the work moves forward. ### Include agents outside Pascal Use governed OpenInference ingestion for external applications. Keep externally reported observations identifiable alongside native Pascal evidence. ## Connected context Tasks and Workrooms hold the investigation. Evaluation turns selected evidence into cases and measured comparisons. Business records and action confirmations establish what happened in the operation. - Observation sources and captured calls - Saved views and quality monitors - Linked Tasks, records, and investigation evidence ## Controls and permissions Source permissions govern captured content. Observation coverage, reported output, approval, and confirmed action remain separate facts. ## Example A support agent says a refund has been issued. The captured evidence shows no confirmed refund. The team inspects the policy call, records the failure, and prepares an evaluation case that requires approval before a refund promise. ## Workflow ### Find the failure - Locate the captured refund promise and the calls around it. ### Inspect the evidence - Read what the application reported and distinguish the response from a confirmed refund. ### Prepare a regression case - Keep the original request and supply a reviewed expectation: check the policy and request approval. ### Compare two releases - Inspect the same case on the baseline and candidate, including their different responses. ### Review the decision - One candidate result is missing. The comparison remains inconclusive and calls for more evidence. ## Next steps Bring an agent workflow and a recurring problem. Trace the evidence your team needs to investigate it. - [Contact sales](https://www.trypascal.io/contact) - [Explore Agent Evaluation](https://www.trypascal.io/platform/evaluation) --- # Pascal Agent Evaluation Source: https://www.trypascal.io/platform/evaluation Know whether the next version is better. Compare agent releases, models, and instructions on the same cases. Inspect regressions, bring in human judgment, and carry the evidence into your release decision. ## Capabilities ### Build useful datasets Author or import cases and curate captured failures. Keep reference answers, source lineage, and dataset versions available for review. ### Define what good means Combine deterministic checks, Python scorers, model judges, and classifiers. Publish exact evaluator versions and test them on examples. ### Compare variants in a playground Run the same cases across models, instructions, or exact Agent Releases. Inspect outputs and scores, then rerun the cases that need attention. ### Look beyond an average Compare paired outputs and relevant slices. Review uncertainty, regressions, and missing results before accepting a candidate. ### Bring in human judgment Use independent reviews and adjudication to resolve disagreements. Compare judge results with accepted human labels and inspect calibration coverage. ### Turn failures into regression cases Explore behavior distributions and failure groups. Review examples, retain accepted expectations, and publish cases for the next evaluation. ## Connected context Start with captured evidence in Observability. Bring in independent human review through Lab. Carry the evaluation into the next agent draft and release decision. - Versioned datasets and frozen evaluation samples - Evaluator versions and exact agent variants - Runs, paired comparisons, and human review ## Controls and permissions A comparison retains its exact cases, evaluators, and targets. Missing results remain unscored, and a favorable example does not authorize a release. ## Example The support team compares releases 3 and 4 against refund cases. The candidate requests approval on the disputed case, but another planned result is missing. The team keeps the comparison inconclusive and collects more evidence before making a release decision. ## Workflow ### Find the failure - Locate the captured refund promise and the calls around it. ### Inspect the evidence - Read what the application reported and distinguish the response from a confirmed refund. ### Prepare a regression case - Keep the original request and supply a reviewed expectation: check the policy and request approval. ### Compare two releases - Inspect the same case on the baseline and candidate, including their different responses. ### Review the decision - One candidate result is missing. The comparison remains inconclusive and calls for more evidence. ## Next steps Choose an agent, the failures that matter, and the criteria your team would trust to judge an improvement. - [Contact sales](https://www.trypascal.io/contact) - [Explore Agent Observability](https://www.trypascal.io/platform/observability) --- # Pascal MCP Servers Source: https://www.trypascal.io/platform/mcp-servers Your business, available to AI. Give compatible AI clients the tools and context to work with your business. Assemble an MCP server visually, test what it can do, and keep access under your control. ## Capabilities ### Build without server code Start from a knowledge, analyst, operations, or integration template—or a blank server. Give it a purpose and choose the capabilities it needs in a guided builder. ### Bring tools and context together Combine callable operations, readable resources, and reusable prompts. AI clients get a clear way to find information and take the next permitted step. ### Reuse knowledge deliberately Import a specific Context Package version. Inspect compatible items and limitations, then review the changes before moving to a newer version. ### Test the actual saved draft Choose a capability, enter inputs in a form, and run it as an available test identity. Inspect the response and access decision before making a release decision. ### Keep access in the business Scope server access to workspace roles and teams. Each request still follows current membership, capability permissions, connection availability, and required approvals. ### Release with a stable address When hosting is enabled, publish an immutable version behind one stable endpoint. Make changes in the draft, release deliberately, and return to an earlier released version when needed. ## Connected context Integrations connect the systems behind your tools. Dynamic Context supplies reusable knowledge packages. MCP Servers makes selected capabilities available through the Model Context Protocol, while the Pascal products behind them keep control of their data and actions. - Tools: selected business operations with their existing inputs, permissions, and approval requirements - Resources: readable knowledge and data supplied by the products that own them - Prompts: reusable instructions with named inputs and linked resources - Context imports: exact package versions with visible compatibility and deliberate upgrades ## Controls and permissions Your workspace decides who can reach the server; each capability decides what that person can do. Connected-account credentials remain private. Draft authoring and friendly tests are available before hosted access. Remote client connections and publication require the deployment’s OAuth interoperability checks and hosting to be enabled. ## Example A customer-success manager is preparing for a Northstar renewal. The team’s MCP server brings together an account lookup, the customer playbook, and a reusable briefing prompt. A compatible AI client can use those selected capabilities to prepare the conversation. Any later action still needs its own permissions and approvals. ## Workflow ### Select the work the client can do - The Customer success server includes Find customer accounts, a customer playbook, and an account-brief prompt. The selected lookup retains its read permission; adding it to a server does not widen access. ### Choose who can use it - Review workspace sign-in and limit the server to the Customer success team. The server’s audience and the permissions of each capability both apply when a request arrives. ### Check the result before release - Test Find customer accounts with Northstar as the input. The saved draft returns the illustrative account and an access decision. A successful draft test does not establish a hosted client connection. ## Next steps Start with one team, one client, and the tools and knowledge the job needs. We’ll help you define the scope and verify the connection before rollout. - [Plan your MCP server](https://www.trypascal.io/contact) - [Pascal Work](https://www.trypascal.io/solutions/pascal-work) --- # Pascal Signal Flows Source: https://www.trypascal.io/platform/signal-flows A data change. A clear next step. Investigate changes in your data, bring a proposed response to review, and follow it through to a confirmed result. ## Capabilities ### Schema Drift Repair A source schema changes. Investigate the affected relationship and bring a cited mapping proposal to review. Saving the proposal leaves the live mapping unchanged. ### Quality Anomaly Investigator A quality check flags an anomaly. Gather the supporting evidence and return a cited diagnosis for the team, without changing data. ### Materialization Triage A refresh fails. Investigate the failure and propose a reviewed dry run or live materialization run. Keep the confirmed run attached to the investigation. ### Object Set Watcher Records enter or leave an object set. Investigate the change and propose running an allowed Workflow, with its scope and review requirements attached. ### Model Monitor Analyst A model monitor raises a signal. Inspect the retained production evidence and propose an Evaluation run to investigate the behavior. ### Destination Sync Guard A destination sync fails. Investigate the failure and prepare a writeback proposal for review. Sending the change to the external system remains a separate step. ## Connected context Bring source events and agent investigations into one record. Use the findings to propose a mapping change, refresh a dataset, start a Workflow, evaluate a model, or prepare a destination update. - Source streams, object sets, materializations, model monitors, and destinations - Saved source evidence, released agent deployments, allowed actions, and review policies - Immutable flow versions, run histories, review decisions, and owner confirmations ## Controls and permissions Choose the source, agent, allowed actions, and reviewers. Test a draft without live changes, then publish and activate it. Each run keeps its evidence and decisions, including any result that still needs confirmation. ## Example The Orders stream renames customer_id to customer_reference. An active schema guard brings the before-and-after schema and mapping evidence into an investigation. Pascal proposes a change to one source mapping, preserving the customer relationship. A data operator reviews the exact proposal. Object Binding confirms that the approved proposal was saved. The run retains the evidence, approval, and confirmation; applying the mapping is a separate action. ## Workflow ### Set the response before the signal arrives - Orders schema guard watches the source, brings the schema and customer mapping into the investigation, and requires a data operator to review any proposal. Version 3 is confirmed live in this example. ### A renamed field starts the investigation - The Orders stream replaces customer_id with customer_reference. Open the run to see the source event and the customer relationship that needs attention. ### See why the agent proposes a change - Read the finding alongside three source references and two checks. The proposed mapping points the customer relationship at the renamed field. ### Review the exact proposal - The review brings the evidence, before-and-after preview, and affected items together. A data operator decides whether to save the proposal. No source records would change. ### Confirm what actually happened - The run waits for confirmation after approval. It completes when the mapping service confirms the proposal was saved. The live mapping remains unchanged; applying it is a separate action. ## Next steps Choose a signal your team already handles. Define the evidence an agent needs, the changes it may propose, and the review required before action. - [Contact sales](https://www.trypascal.io/contact) - [People and agents working together](https://www.trypascal.io/solutions/pascal-work) --- # Pascal Ontology Source: https://www.trypascal.io/platform/ontology A shared language for your business. Connect records across systems into a shared model of your customers, shipments, assets, and relationships. Give people and agents the same business context. ## Capabilities ### Model the company in its own terms Define object types, fields, relationships, and interfaces for customers, assets, orders, or anything else the business operates on. ### Resolve identity across systems Bring different source records back to the same business object. A customer remains recognizable across finance, sales, and operations. ### Inspect the evidence behind a value Follow important fields to their sources and change history. Understand where a value came from before relying on it. ### Explore the connected record Move from a record to its related objects, documents, events, and available actions without reconstructing the context in another tool. ### Create reusable object sets Define live collections such as at-risk orders or open cases. Reuse the same scoped business population in analysis, workflows, and applications. ### Attach actions to business objects Make approved operations available where the work happens. Carry current permissions and review requirements into the action. ## Connected context Connect source records with Integrations and Data Infrastructure. Use the same business objects in Atlas investigations, Compass processes, Workflows, applications, and agent Tasks. - Customers, assets, orders, shipments, cases, and the relationships between them - Business definitions, calculated knowledge, histories, lifecycles, and live collections - Approved actions, operating rules, policies, and the evidence behind every change ## Controls and permissions Your ERP, CRM, and other source systems keep control of their records. Ontology connects those records without losing their origins. Actions on a business object still require current permission and any necessary approval. ## Example A carrier failure arrives as a notice in one system. The response depends on orders, delivery promises, containers, and compliance cases in several others. Ontology connects them around the shipment, so an operator can investigate the exception and see which actions are permitted from the same record. ## Workflow ### Start with a shared identity - Open Shipment MDR-80421. The delivery promise, carrier, and compliance hold belong to the same business record, with the original observations still available. ### Follow the relationships and sources - Move from the shipment to its carrier, container, order, and compliance case. Inspect the carrier field’s source and the earlier mapping it replaced. ### Find the work that needs attention - Filter 42 active Horizon shipments to the 17 at highest risk. The lithium loads remain held; the available next step is to request Compliance review. ## Next steps Bring the decision, the records behind it, and the systems that own them. Map the objects, relationships, and actions your team needs first. - [Contact sales](https://www.trypascal.io/contact) - [Logistics operating system](https://www.trypascal.io/solutions/logistics) --- # Pascal Integrations Source: https://www.trypascal.io/platform/integrations Your systems. Ready for connected work. Bring records, events, and supported actions from your existing tools into Pascal. See what each connection can do and who can use it. ## Capabilities ### Find the connection Explore the connector catalog and the records, queries, and actions each integration supports. ### Connect an account Set up an account with the access the work needs. Keep credentials private and connection scope explicit. ### Bring in business data Connect source records with Pascal’s business model. Retain source identity and the context needed to understand a value. ### Make actions available Give authorized people, workflows, and agents access to supported actions through the same connection. ### Review connection health Inspect account status and capability availability. Resolve missing access or configuration before relying on the connection. ### Control the access Apply current account, workspace, and source permissions when the work happens. Keep the resulting action and its outcome inspectable. ## Connected context Use connected records in Ontology and Data Infrastructure. Give Agents, Workflows, Forge functions, and internal applications access to the same supported tools. - Business applications, databases, warehouses, files, APIs, and event sources - The records, data feeds, incoming events, and approved actions each connection supports - Connected accounts, permissions, delivery history, health, changes, and recovery ## Controls and permissions Credentials stay private, and permissions are checked whenever a connection is used. Changes to an external system remain unconfirmed until that system reports what happened. A retry alone cannot establish success. ## Example An engineering team needs repository context to investigate a change. The GitHub connection supplies repository metadata and pull-request history to the workspace. The team can inspect the connected account and its available reads before deciding whether a later workflow also needs permission to write. ## Workflow ### Inspect the available capabilities - Review repository metadata and pull-request history. Assess the specific operations you need before connecting an account. ### Check the connected account - Inspect the Meridian account, its connection status, and the read operations available to the workspace. ### Match permission to the operation - Repository reads are available in this example. A repository change needs its own write capability and authorization; connecting the account does not grant them. ## Next steps Start with one workflow and the reads, events, or actions it needs. Confirm account access and the supported operations before expanding. - [Contact sales](https://www.trypascal.io/contact) - [Software Factory](https://www.trypascal.io/solutions/software-factory) --- # Pascal Bedrock Source: https://www.trypascal.io/platform/bedrock Turn the business problem into a buildable plan. Connect the evidence, design, and requirements in one Solution Project. Give the team building it a clear account of what needs to change and why. ## Capabilities ### Define the outcome before the solution Frame the operating problem, the people it affects, and the evidence that would demonstrate useful progress. ### Build a source-linked current state Connect interviews, documents, systems, and process evidence to a shared account of how the organization works today. ### Explore architecture in context Relate applications, capabilities, teams, and dependencies. Follow an architectural choice back to the business need behind it. ### Compare possible futures Develop alternatives and inspect their assumptions, dependencies, and tradeoffs before committing to a direction. ### Keep decisions durable Record the evidence, rationale, participants, and unresolved questions so delivery teams understand why the plan took its shape. ### Turn direction into delivery work Connect the chosen approach to a roadmap, accountable work, and the source material teams need to carry it forward. ## Connected context Use Ontology, Compass, and Atlas to understand the current operation. Bring the team together in Workrooms, then connect the agreed requirements to implementation Tasks and the products needed to deliver them. - Project briefs, source evidence, requirements, decisions, and risks - Current processes, proposed designs, and implementation plans - Version history, reviews, deliverables, and links to live resources ## Controls and permissions Keep the plan, implementation, and approval decisions linked. Review the exact version being delivered, and verify the business result separately. Releasing an application does not approve every operating change it supports. ## Example Meridian needs an application for managing operating changes. Its Solution Project connects the current process, target design, and eight lithium requirements to the Factory Control implementation. Engineering can build from that context while Operations and Compliance retain the decisions assigned to them. ## Workflow ### Make the current process explicit - Map how an operating change moves through intake, requirements, implementation, and review. Give the team a common starting point. ### Design the next way of working - Compare the target with today’s process. Connect the implementation Task and release decision so the design leads to accountable work. ### Carry the requirements forward - Keep eight lithium requirements linked to their source bulletin, checks, and implementation. Reviewers can follow the business reason behind each change. ## Next steps Bring one operating problem, its audience, and the evidence you already have. Define the target and the first change worth implementing. - [Contact sales](https://www.trypascal.io/contact) - [Pascal Work](https://www.trypascal.io/solutions/pascal-work) --- # Pascal Data Infrastructure Source: https://www.trypascal.io/platform/data Data your whole operation can use. Turn connected records and files into reusable datasets. Keep their source, quality, freshness, and access rules visible wherever the data is used. ## Capabilities ### Connect the sources you already own Discover tables, files, streams, and APIs through scoped connections. Establish what each source provides and how it should be refreshed. ### Preserve the original evidence Keep source inputs available for replay and reconciliation. Transform the data without losing the material it came from. ### Map records to business identity Normalize source shapes and connect them to canonical business objects, including the relationships downstream work depends on. ### Publish reusable data products Give a dataset an explicit shape, owner, and quality expectations so other teams can build on a maintained output. ### See freshness, quality, and lineage Inspect when data arrived, how it changed, and which consumers depend on it. Make incomplete or stale inputs visible. ### Use data across the platform Query datasets, feed pipelines, supply model inputs, and build object-backed applications under the access policies of the workspace. ## Connected context Connect sources through Integrations and map records with Ontology. Prepare outputs in Data Pipelines, query them in SQL Warehouse, and use them in model development, applications, Workflows, and agent Tasks. - Connected sources, original inputs, schemas, and identity mappings - Published datasets, business object sets, features, and metrics - Quality checks, freshness, lineage, query history, and exports ## Controls and permissions Keep the original source behind each derived dataset. Inspect the inputs, transformations, and quality checks before relying on an output. Previews, published datasets, and approved exports each have a separate purpose and review path. ## Example A lithium readiness check needs dependable telemetry. Data Infrastructure keeps the original ten readings, the reviewed transformation, and the published nine-row snapshot connected. An analyst can see what was excluded and why, while an operator can still find the stale reading that keeps a shipment on hold. ## Workflow ### Keep the original evidence - Inspect Tacoma Port telemetry, including an invalid timestamp and a separate stale reading. Preparation starts with the observations as received. ### Use an exact published output - Open the nine-row snapshot produced by reviewed release v2. Its publication and build are available for inspection; the newer blocked draft is a separate version. ### Follow quality and lineage - Trace the output to the source and the policy that permits one quarantined row. Check freshness and quality before using the data in another decision. ## Next steps Choose a source and the decision it supports. Define the output, its quality rules, and the people or applications that will use it. - [Contact sales](https://www.trypascal.io/contact) - [Pascal Work](https://www.trypascal.io/solutions/pascal-work) --- # Pascal Data Pipelines Source: https://www.trypascal.io/platform/data-pipelines Build data products that hold up to change. Turn source data into maintained datasets. Preview every transformation, resolve quality issues, and publish a version other teams can depend on. ## Capabilities ### Compose the right transformation Combine visual steps, SQL, and code to filter, join, map, aggregate, or enrich data from governed sources. ### Preview before you publish Inspect sample results at each step. Catch a broken mapping or unexpected join while the pipeline is still a draft. ### Define a dependable output Specify the output schema and quality requirements. Give downstream consumers a clear contract to build against. ### Trace changes through the graph Follow source and field lineage to understand which transformations and published outputs a proposed change will affect. ### Run a reviewed version Separate an editable definition from a published pipeline. Keep each run tied to the version, inputs, and configuration it used. ### Operate, investigate, and repair Inspect failed steps, run history, freshness, and output quality. Use replayable inputs to investigate and rebuild affected results. ## Connected context Build from Data Infrastructure sources and make outputs available to SQL Warehouse, applications, and model development. Use Workflows and Automations to coordinate scheduled runs and recovery. - Pipeline drafts, reusable transformations, and published versions - Source data, SQL, code, tests, and output definitions - Previews, lineage, builds, schedules, and failed runs ## Controls and permissions Review the pipeline version and its quality rules before publishing an output. A successful preview helps you assess a draft; only a completed build that passes the required checks can publish a new dataset version. ## Example An invalid timestamp should not quietly become a readiness signal. The pipeline identifies the bad sensor row, exposes the failed check, and keeps the draft from publishing. Consumers can continue to inspect the output of the separately reviewed version and the policy that produced it. ## Workflow ### Connect the transformation - The Lithium telemetry readiness pipeline connects source readings to typed fields, timestamp checks, and a reusable status output. ### Understand the failed check - The preview preserves the malformed timestamp and identifies its source row. Problems explains why draft v3 cannot publish its output. ### Inspect the reviewed output - Reviewed release v2 has a completed build and a published nine-row snapshot. Its quality policy permits one quarantined row; the blocked draft stays blocked. ## Next steps Start with one source, one useful output, and the checks that determine whether that output is fit for use. - [Contact sales](https://www.trypascal.io/contact) - [Pascal Work](https://www.trypascal.io/solutions/pascal-work) --- # Pascal SQL Warehouse Source: https://www.trypascal.io/platform/sql-warehouse Ask in SQL. Answer in business terms. Query your business objects and datasets with SQL. Explore the result, inspect its source context, and return to the query that produced it. ## Capabilities ### Find the right dataset Explore available business objects and data products with descriptions, schemas, and their source context close at hand. ### Write SQL with business meaning Query shared object and dataset definitions. Reuse the organization’s understanding of customers, orders, and other business concepts. ### Respect the current access policy Keep query access scoped to the actor and workspace. Apply the relevant record and field controls before results are returned. ### Understand the work a query requires Inspect the available execution path and applicable limits. Make resource requirements part of the query decision. ### Keep a history you can follow Return to prior queries and their recorded results. Trace the inputs and execution behind an analysis someone shares with you. ### Put the answer into the next step Use query results in an investigation or a downstream workflow, with their source references and permissions still attached. ## Connected context Query data from Data Infrastructure and shared business definitions from Ontology. Reuse useful queries in Data Pipelines, notebooks, dashboards, applications, and agent investigations. - Business objects, datasets, schemas, and query views - Warehouses, sessions, saved queries, and reusable metrics - Query history, retained results, execution plans, and exports ## Controls and permissions Queries use the current workspace and data permissions. An empty answer, denied access, and a failed query remain distinct. Saving, publishing, or exporting a result requires the appropriate separate action. ## Example Operations asks which Tacoma loads are ready. The analyst opens the saved query and finds five ready loads and two blocked loads. Query history preserves the result for the next reviewer; shipment actions still follow their own approval process. ## Workflow ### Ask the operating question - The saved query checks current telemetry and shipment-specific approval. Its purpose is precise: understand which loads are ready. ### Read the result in context - Seven Tacoma inbound loads appear in the retained result: five ready and two blocked. Readiness in a query does not authorize tendering. ### Return through query history - Open the saved execution and its result. The team can inspect the same answer later, with unavailable execution details clearly identified. ## Next steps Bring the source data, the access it requires, and the result your team needs to inspect or share. - [Contact sales](https://www.trypascal.io/contact) - [Pascal Work](https://www.trypascal.io/solutions/pascal-work) --- # Pascal Automation Studio Source: https://www.trypascal.io/platform/automation-studio Turn past work into automation. Build agents and workflows from the cases your team already handles. Test them on unseen work, choose a limited scope, and expand as results justify it. ## Capabilities ### Reuse what your team knows Bring past cases and decisions. Keep the evidence, missing history, and exceptions that make the work more than a checklist. ### Build with an agent Give the builder an outcome and development examples. Review the resulting Agent and Workflow releases before putting them to work. ### Keep the test unseen Use a separate set of unfamiliar cases. Failed and missing trials stay in the results, alongside completions and correct handoffs. ### Start with a small scope Choose which work can enter and how much to expose. Keep the required approvals, pause new work, or restore a previous configuration. ### Give exceptions a human path Send disputed contracts, missing identity, and privileged requests to a person with the reason for the handoff and access to the original case. ### Follow the outcome See what completed, what reopened, and what still needs evidence. Track human participation separately from automated completion. ## Connected context Use Work Episodes for case history, Tasks for the build, and Evaluation for testing. Run reviewed Agent and Workflow releases with records from Ontology, evidence from Documents, and actions from Integrations. - A work model defining the outcome, source evidence, and decisions reserved for people - Historical work examples, separate development and protected case sets, and exact releases - Assessment results, operating scope, human review requests, and observed outcomes ## Controls and permissions Your team sets the outcome, operating scope, and decisions reserved for people. Tests show how a candidate performed in the test environment. Live actions still require current permissions, and business results need later evidence from the systems involved. ## Example A support team wants to resolve standard entitlement requests. It brings historical tickets, reviews the identity and contract checks, and reserves disputed requests for a specialist. The builder uses development examples; a separate protected set tests the released workflow. The team starts with a limited, supervised scope. In operation, disputed entitlement stays in the human queue, and a resolved ticket remains a pending outcome until the seven-day reopen window is observed. ## Workflow ### Understand the work - Show how a case starts, what a good outcome looks like, and where your team needs to step in. ### Build the automation - Work with an agent using development examples. Review the proposed process and select the exact release you want to test. ### Test on unseen cases - Hold back examples the builder has never seen. Look at completions, correct handoffs, and failures together. ### Choose the operating scope - Choose the eligible work and how much to expose. Check the trigger, approvals, and human fallback before enabling new work. ### Operate and improve - Resolve exceptions and watch what happens after a run finishes. Send improvements through another build and test cycle. ## Next steps Bring a recurring case type, examples of good decisions, and the exceptions people should keep handling. Define how to test the automation before expanding its scope. - [Contact sales](https://www.trypascal.io/contact) - [People and agents working together](https://www.trypascal.io/solutions/pascal-work) --- # Pascal Workflows Source: https://www.trypascal.io/platform/workflows Keep work moving across every handoff. Coordinate people, agents, and systems through repeatable processes. Keep progress intact through long waits, human reviews, and failed steps. ## Capabilities ### Define the sequence Connect the steps, inputs, and conditions that make up a repeatable operation. ### Coordinate across systems Compose approved business functions and connected tools. Keep each step tied to its input and expected result. ### Wait for the right moment Pause for a person, signal, or scheduled point without losing the work already completed. ### Keep progress visible Follow a run through its steps, waiting states, failures, and completed results. ### Recover with context Inspect what happened before retrying or repairing a failed step. Preserve completed work and uncertain outcomes. ### Review the version Keep a run connected to the workflow definition it uses. Review changes before applying a new version. ## Connected context Combine agent recommendations and Forge functions in a process connected to Compass cases. Start deployed Workflows from schedules, webhooks, or supported platform events through Automations. - Revisioned drafts and immutable releases - Deployments and runs - Steps, waits, outputs, and human tasks ## Controls and permissions Review and publish a version before deploying it. Each run records the steps and results it confirms, including work still waiting or unresolved. Requesting a change to a run does not mean that change has finished. ## Example A recovery decision creates follow-up work across carriers and customs. The Workflow connects those steps and retains their outputs. In this example, all three steps have completed, but completion updates are still finalizing. The team can inspect the recorded work while keeping that unresolved status and the three lithium holds visible. ## Workflow ### Understand the defined process - The Workflow connects confirmed tender writebacks to carrier and customs follow-ups. Three hazardous loads remain outside the approved shipment scope. ### Open the recorded run - The run history shows a seven-second execution. Open it to inspect the steps, outputs, and any completion work still pending. ### Check the result and remaining work - Three steps are complete. The final output records 14 approved shipments and three held loads. Completion updates are still finalizing, so the run remains unconfirmed until those updates arrive. ## Next steps Choose a workflow that crosses teams or systems. Map its steps, approvals, waiting periods, and what should happen when a step fails. - [Contact sales](https://www.trypascal.io/contact) - [Logistics](https://www.trypascal.io/solutions/logistics) --- # Pascal Compute Source: https://www.trypascal.io/platform/compute Run the calculation. Keep the context. Run analytical and computational jobs with defined inputs, resources, and outputs. Trace each result to the code, environment, and logs behind it. ## Capabilities ### Define a reproducible job Package the code, dependencies, configuration, and expected outputs needed to repeat a computational task. ### Bring governed inputs Bind the datasets, documents, and model artifacts the job needs. Keep the input selection connected to its origin and access scope. ### Choose the required resources Declare the environment and capacity needed for the workload, then use an approved execution path that can satisfy them. ### Check the run before it starts Validate the job configuration and available capacity. Inspect applicable limits and cost information before execution. ### Follow progress and failure Inspect the run’s state, logs, and intermediate work. Distinguish queued, running, failed, and completed jobs. ### Keep useful results durable Collect outputs with the run that produced them. Reuse those artifacts in model development, analysis, or the next operational step. ## Connected context Use datasets and files as inputs, coordinate jobs with Workflows, and carry outputs into analysis, model development, or Atlas scenarios. Keep the job connected to the decision it supports. - Job definitions, environment versions, and workload profiles - Input files, resource limits, network rules, and checkpoints - Logs, usage, cost information, and saved outputs ## Controls and permissions A job needs an available environment, capacity, and permission to run. Completion confirms the computation, while its output still needs to be assessed for the intended use. Any resulting business action requires its own authorization. ## Example A carrier recovery needs a capacity calculation. The team opens the optimizer job from its Task, inspects the execution details, and reads the retained logs. The calculation supports the recovery decision, and the operator remains responsible for approving any carrier change. ## Workflow ### Open the job from the work - The recovery Task retains the optimizer result. Follow its link to the completed job rather than reconstructing the computation elsewhere. ### Inspect the execution details - Review the Python runtime, machine resources, timing, and completion status associated with this run. ### Read the result with its context - The retained logs describe the input and candidate capacity. The team can use that evidence in a routing decision; computation itself does not change a carrier booking. ## Next steps Bring the workload, its inputs, the resources it needs, and the output your team will use to decide what happens next. - [Contact sales](https://www.trypascal.io/contact) - [Pascal Work](https://www.trypascal.io/solutions/pascal-work) --- # Pascal ML Source: https://www.trypascal.io/platform/ml Build predictions around real decisions. Define what a useful prediction must do. Train candidates, compare their results, and test the failure cases that matter before proposing a release. ## Capabilities ### Start with the prediction Define the target, decision, evaluation metrics, and operating constraints before selecting a model or training approach. ### Prepare data without leaking the answer Choose governed inputs, define features, and preserve the separation between training and evaluation data. ### Run comparable experiments Keep datasets, feature choices, parameters, and environments connected to each training run so candidate results can be compared. ### Evaluate against the real objective Review model quality alongside latency, cost, and the constraints of the business decision. Keep a baseline for comparison. ### Deliver an exact model version Connect a selected release to batch or online prediction. Retain the evaluation and training lineage behind the deployed model. ### Learn from operating feedback Connect observations and labels to monitoring. Use performance changes to guide a reviewed decision about evaluation or retraining. ## Connected context Use Data Infrastructure and Data Pipelines for inputs, Compute for jobs, and Models to connect the objective, evaluation, and release decision. Keep the training data and results available for review. - Prediction objectives, training data, features, and held-out cases - Training jobs, candidates, metrics, and evaluation results - Model versions, prediction outputs, and monitoring evidence ## Controls and permissions Compare candidates against the same criteria and inspect performance on critical groups. A better overall score can still hide an unacceptable failure. Selecting a candidate, releasing it, and putting it into use are separate decisions. ## Example Missing a hazardous shipment can matter more than a small gain in average prediction quality. Meridian’s evaluation makes that tradeoff visible: Trial 3 improves the overall score but misses the recall requirement for lithium loads. The team keeps the decision and the reason to continue the study. ## Workflow ### Define the prediction and its use - Predict which shipments may miss the 21:00 cutoff using information known at the decision time. The intended use is human-reviewed recovery. ### Compare the same evaluation - Inspect three candidates against the same held-out data. Trial 3 leads overall, but its hazardous-load recall is 84%, below the 90% minimum. ### Record the next decision - Continue study retains the reason to improve hazardous-load recall. The comparison does not select a new model release. ## Next steps Define the target, the information available at decision time, and the mistakes that would make a model unsuitable for the work. - [Contact sales](https://www.trypascal.io/contact) - [Pascal Work](https://www.trypascal.io/solutions/pascal-work) --- # Pascal Documents Source: https://www.trypascal.io/platform/documents Every finding, a path back to the source. Turn documents into facts your team can check. Keep extracted fields and findings linked to the original page, passage, and version. ## Capabilities ### Organize a governed corpus Bring files into a shared collection with their source, scope, and access requirements. Keep new versions connected to the original document. ### Work with real document structure Process native and scanned material while retaining pages, sections, tables, figures, and the structure needed to interpret a finding. ### Extract facts with citations Turn a clause, value, or table into a structured finding that points back to the source page and passage. ### Compare extraction approaches Try a bounded sample with different strategies or providers. Review result quality before processing a larger collection. ### Make uncertainty reviewable Keep ambiguous fields and conflicting findings available for human review. Preserve corrections with the evidence behind them. ### Put findings into business work Use extracted evidence in research, business records, and workflows without stripping away the citations that make it inspectable. ## Connected context Bring document evidence into business records, agent Tasks, and Dynamic Context packages. Give reviewers in Workrooms the source passage behind a finding or proposed change. - Source documents, pages, versions, and document sets - Extracted fields, tables, passages, and citations - Processing runs, reviews, corrections, and evaluations ## Controls and permissions An extracted statement still needs the review required by the work. Keep the source version and any corrections attached to the finding. Publishing a finding does not approve an operating change based on it. ## Example A new bulletin changes the requirements for lithium shipments. Documents keeps the source text beside the finding so Operations and Compliance can check the wording, resolve the outstanding question, and use the accepted evidence in their operating review. ## Workflow ### Read the requirement at its source - The port bulletin requires current telemetry and shipment-specific Compliance approval before tendering a lithium load. ### Inspect the outstanding finding - A separate publication-timing finding still needs review. The team can distinguish the extracted statement from an accepted operating change. ### Keep the passage beside the review - Return to the exact wording and document version. The reviewer has the source needed to judge the finding; no review is submitted in this walkthrough. ## Next steps Choose a document-heavy process and the findings your team needs to verify. Start with the original files and a clear review responsibility. - [Contact sales](https://www.trypascal.io/contact) - [Pascal Work](https://www.trypascal.io/solutions/pascal-work) --- # Pascal Compass Source: https://www.trypascal.io/platform/compass See where work stands. Know what comes next. Connect the intended process to live cases, deadlines, and exceptions. Find the work that is stuck and the next step your team can take. ## Capabilities ### Define the process Model the states, owners, rules, and service levels that shape an operation. Review a version before it becomes the active lifecycle. ### Operate every case Move between tables, boards, and case details. See the owner, current state, dependencies, and next available action. ### Find the real path Connect source events and records to see how work actually moves. Inspect variants, waiting time, loops, and handoffs. ### Investigate the bottleneck Compare routes, teams, and business dimensions. Trace delays and deviations to affected records and source evidence. ### Review the improvement Turn findings into proposed changes and intervention queues. Compare an alternative with the baseline before changing the active process. ### Follow the outcome Keep lifecycle changes, workflows, agent work, and external actions visible. Reconcile uncertain results before retrying the work. ## Connected context Use Ontology for business records, Workflows for repeatable steps, and Atlas for wider dependencies. Bring the case and its history into agent investigations and team reviews. - Lifecycle definitions and released versions - Cases, events, and operating queues - Process findings and improvement proposals ## Controls and permissions The current process defines which transitions are allowed. Investigating a delay or drafting a change does not alter that process. Required reviews stay open until the responsible people complete them. ## Example A shipment can have fresh telemetry and still be blocked by missing approval. Compass shows both facts alongside the case clock and responsible reviewer. The team can request the available review while separately assessing a change to the process definition. ## Workflow ### Find the cases that need attention - The lithium queue contains three held shipments assigned to Jordan Lee. Each has a review clock, a current state, and a reason it cannot proceed. ### Examine the proposed process - Draft v13 adds Battery telemetry review before Carrier tender. Its guard requires telemetry no older than 15 minutes and current Compliance approval. ### See what still needs review - Two of four readiness checks are complete. Operations and Compliance approval are missing, so active v12 remains the running process. ## Next steps Choose one case type. Map its states, deadlines, decision owners, and the evidence needed to move it forward. - [Contact sales](https://www.trypascal.io/contact) - [Logistics operating system](https://www.trypascal.io/solutions/logistics) --- # Pascal Atlas Source: https://www.trypascal.io/platform/atlas See the impact before you make the change. Explore the relationships behind your operation. Trace a disruption, compare possible responses, and bring the assumptions into the decision. ## Capabilities ### Explore the relationships See how customers, assets, facilities, and other business records connect across the operation. ### Inspect the record Open an object and follow its attributes and relationships back to the source. ### Find the affected work Trace a changed condition through related objects to understand the wider impact. ### Define the alternative Record a scenario’s assumptions, scope, and proposed changes alongside the baseline. ### Compare the results Review the measures, tradeoffs, and unresolved constraints of a scenario against its baseline. ### Keep the decision explicit Separate exploring a scenario from authorizing an operating change. Carry the evidence into the review. ## Connected context Explore Ontology records alongside process context from Compass and source evidence from Data and Documents. Connect scenario findings to Tasks and Workflows for review and action. - Business records and relationships - Investigations and saved system views - Scenarios, assumptions, and comparison results ## Controls and permissions Scenario results depend on their inputs and assumptions. Compare them with the baseline before acting. A completed simulation leaves the live operation unchanged; the chosen response still needs approval and execution. ## Example An available capacity slot is only one part of a feasible recovery. Atlas connects the carrier, shipments, and lanes, then shows a scenario beside its baseline. The team can inspect the assumptions before taking the eligible reroutes into the operating approval. ## Workflow ### Trace the connected impact - Find Horizon Freight and its shipments and lanes. The risk filter selects the same 17 high-risk shipments in the graph and table. ### Compare the modeled alternative - Inspect the fixed inputs and fallback capacity behind the scenario. Its projected service result assumes required future approvals; three lithium holds remain. ### Bring the proposal to its decision owner - Open the linked Task for 14 eligible reroutes. The operator can review the exact proposal; the Atlas comparison itself has not moved a shipment. ## Next steps Bring the objects a change could affect, a baseline to compare against, and the constraints that make a response feasible. - [Contact sales](https://www.trypascal.io/contact) - [Logistics operating system](https://www.trypascal.io/solutions/logistics) --- # Pascal Agents Source: https://www.trypascal.io/platform/agents Give AI a real job. Give an agent a clear assignment, relevant business context, and the tools to help. Guide its progress and review its work in a shared Task. ## Capabilities ### Define the assignment Build an agent around a business purpose. Give it the skills, instructions, and expected work product the job needs. ### Connect useful context Bring governed records, documents, and prior work into the Task. Keep claims connected to the evidence behind them. ### Put agents to work Assign a durable Task and follow its progress. Add direction, answer questions, or pause the work as the situation changes. ### Review consequential actions See proposed changes and their required approvals. Keep the decision, attempted action, and confirmed result distinct. ### Keep the work product Carry reviewed reports, plans, code, and other outputs beyond the conversation, with their sources and version history. ### Resume and improve Investigate captured failures, turn reviewed examples into regression cases, and compare exact releases before deciding what to change. ## Connected context Agents use business records, documents, Models, Workflows, and connected tools. Workrooms brings in the team, while Dynamic Context and Context Graph provide relevant knowledge and reviewed decisions. - Agent definitions, skills, and releases - Tasks, decisions, and action history - Source context and reviewed work products ## Controls and permissions An assignment sets the job; current permissions determine what the agent may access or change. Review consequential proposals and inspect the confirmation from the system that performed the action. ## Example An operator asks for compliant reroutes before the delivery cutoff. The Task brings together 42 affected shipments and the fallback agreement so the operator can inspect the evidence behind the work. Agent configuration and deployment define the available assistant; consequential routing decisions still require their assigned approval. ## Workflow ### Define the assignment - Review the Engineering Agent’s purpose, goals, examples, and boundaries. Draft revision 2 includes a new regression case and has not been released. ### Inspect the reviewed version - Release 1 retains the independently reviewed configuration. Changes to the draft do not alter that release or the Tasks already using it. ### Choose where it can operate - Deployment 1 makes Release 1 available to Meridian engineering with the selected policy and budget. Future Tasks still need approval for the actions they request. ## Next steps Choose a recurring assignment, its sources and tools, and the decisions that should come back to your team. - [Contact sales](https://www.trypascal.io/contact) - [Pascal Work](https://www.trypascal.io/solutions/pascal-work) --- # Pascal RL Source: https://www.trypascal.io/platform/rl Make the next response better informed. Turn reviewed responses into evidence for improvement. Capture which answer was better, why it was preferred, and what the next candidate needs to demonstrate. ## Capabilities ### Choose the behavior to improve Choose a recurring decision or failure. Define the result you want to improve, the examples to review, and how the judgments will be used. ### Keep the original comparison Compare the original responses with their source context. Hide model identities and scores during review so people can judge the answers on their merits. ### Make the rubric explicit Define the review criteria, rating scales, and questions. Keep the rubric version with each response so later readers can understand the judgment. ### Resolve disagreement Collect independent judgments and apply the agreed review rules. Send unresolved disagreements to another reviewer. ### Retain the accepted case Retain the final judgment, the reviews behind it, and the exact source example. Give future evaluations a case the team can inspect. ### Propose the next improvement Propose a next step for Evaluation, Training, or Serving. Each product checks the inputs, permissions, and review needed before acting. ## Connected context Bring response pairs from Models and Evaluation into review. Retain the original source and accepted judgment so later evaluation or training can use the case under its own requirements. - Improvement objectives, source examples, and review rubrics - Independent reviews, disagreements, and accepted judgments - Evidence references and proposals for further evaluation or training ## Controls and permissions Human review records a judgment. It does not train, deploy, or authorize a model change. Each later step needs its own inputs, evaluation, and approval. The walkthrough shows an accepted review, not a self-updating model. ## Example Both responses see fresh telemetry, but only one respects the pending approval. Reviewers prefer the response that keeps the shipment held and retain the source and rubric behind that choice. A future improvement can start with an inspectable case instead of an unexplained thumbs-up. ## Workflow ### Compare the responses - One response keeps the Compliance hold. The other would tender while approval is still pending. Current telemetry satisfies only one of the required conditions. ### Inspect the basis for the judgment - Expand the retained source item and rubric version. Reviewers can see the evidence the preference was based on. ### Keep the accepted evidence - The preference remains connected to its source and review. It is evidence for further improvement; this comparison does not train a model or publish a release. ## Next steps Choose a recurring failure, define what a better response would do, and collect reviewed examples with the evidence needed to judge them. - [Contact sales](https://www.trypascal.io/contact) - [Pascal Work](https://www.trypascal.io/solutions/pascal-work) --- # Pascal Workrooms Source: https://www.trypascal.io/platform/workrooms One room for the people moving the work forward. Bring people, agent Tasks, documents, and decisions together around a shared outcome. Give every handoff the context it needs. ## Capabilities ### Start with a shared purpose Create a room around an incident, customer, project, or recurring operation. Give the team a common scope and clear ownership. ### Bring the team together Invite people and resident agents with defined roles. Keep membership and access connected to the work they need to do. ### Keep context close Attach business records, documents, process views, and other sources. Follow the evidence without losing the conversation. ### See what needs you Bring mentions, waiting decisions, failed work, and assigned reviews into one attention view. Pick up at the right point after a handoff. ### Turn discussion into work Connect threads with Tasks, workflows, and reviewable actions. Keep progress and results visible to the people responsible. ### Keep the operating record Retain decisions, sources, files, and outcomes in an ordered history. Give the next person the context behind what happened. ## Connected context Bring business records, Documents, Atlas investigations, and Compass cases into the conversation. Link Tasks and Workflows so the team can follow progress and review the result together. - Rooms, membership, and resident agents - Conversations, decisions, and operating history - Linked context, Tasks, and work products ## Controls and permissions A room brings the team together; each linked source keeps its own access rules. Use the approval action required by a release or operating change. Discussing a decision in the room does not approve it. ## Example Engineering is building Factory Control while Operations and Compliance review a lithium process change. Their Workroom connects the shared brief and both Tasks, so the team can follow the implementation without mistaking software delivery for an approved operating policy. ## Workflow ### Start with the shared brief - Keep the purpose, people, and connected work together. Everyone can see what the team is trying to deliver. ### Follow the implementation - Open the Factory Control Task from the room. Its working copy and review state stay connected to the assignment. ### Keep the open decision visible - The lithium operating review still names its pending reviewers. Delivering the application does not close that separate Operations and Compliance decision. ## Next steps Choose an outcome, invite the people responsible, and connect the Tasks and evidence they need to move it forward. - [Contact sales](https://www.trypascal.io/contact) - [Pascal Work](https://www.trypascal.io/solutions/pascal-work) --- # Pascal Dynamic Context Source: https://www.trypascal.io/platform/dynamic-context The right knowledge for the job at hand. Package the knowledge a recurring job needs. Test which sources are included, see what permissions exclude, and keep the right versions within reach. ## Capabilities ### Build a library around real jobs Create reusable knowledge packages for an investigation, team, or recurring assignment instead of assembling the same background every time. ### Combine the formats your work needs Bring documents, business records, and structured knowledge into one package while keeping each item linked to its source. ### Choose the source precisely Identify which collection, version, or record population belongs in the package. Make required information explicit. ### Compose company and task knowledge Combine reusable organizational context with the more specific material needed by a team, application, or individual task. ### Apply permissions when context is used Assemble knowledge for the current actor and workspace. A reusable package does not give its consumer new access rights. ### Inspect and improve the package Test what the package includes, review missing or optional material, and keep changes versioned as the job evolves. ## Connected context Assemble relevant records, documents, process context, and reviewed decisions from across Pascal. Reuse those packages in Agents, Workrooms, and applications under each participant’s current access. - Context packages, source selections, audiences, and versions - Connections to agents, Tasks, rooms, teams, and applications - Test requests, citations, omissions, and delivery records ## Controls and permissions A context package never grants access to its sources. Permissions are checked when material is assembled and used. A preview shows the test output; only a delivery record can establish what was supplied to an actual agent run. ## Example A lithium compliance question needs a current bulletin, but it does not grant access to restricted review notes. Dynamic Context makes the included version and the permission omission visible in the preview, so the team can assess the package before using it with an agent. ## Workflow ### Test a specific request - Ask about current telemetry and pending approval. Preview the context that this job-specific request would use. ### Inspect the included knowledge - The preview includes the approved port bulletin and its source version. Review the material that supports the answer. ### Understand what is omitted - Compliance review notes remain excluded when permission is denied. A context package does not bypass the access rules of its sources. ## Next steps Start with the questions the agent must answer, the sources it may use, and the access boundaries the context must respect. - [Contact sales](https://www.trypascal.io/contact) - [Pascal Work](https://www.trypascal.io/solutions/pascal-work) --- # Pascal Context Graph Source: https://www.trypascal.io/platform/context-graph Keep the decision. Remember why. Preserve decisions with their evidence and history. Help the next person or agent understand the precedent, what changed, and what still applies. ## Capabilities ### Keep institutional memory Retain useful decisions, lessons, and operating context beyond a single conversation. ### Follow the evidence Connect a memory document to the sources and reasoning behind it. ### Review what is current See review status and aging information before using a memory in new work. ### Connect related work Bring relevant records, decisions, and prior outcomes into the same context. ### Use memory with care Apply current access and source permissions when people or agents retrieve information. ### Learn from the outcome Carry reviewed lessons into future assignments while keeping current source evidence authoritative. ## Connected context Connect decisions to Compass cases and Atlas investigations. Use Dynamic Context to bring accessible, relevant precedents into the next assignment. - Memory records, source citations, revisions, and review candidates - Rationale, alternatives, owners, scope, and review dates - Conflicts, replacement records, and access policy ## Controls and permissions Review memory before treating it as current guidance. Source records still determine today’s facts, and a previous approval does not grant permission to repeat an action. Context Graph retains business rationale, not private model reasoning. ## Example A team remembers that a weekly roster once justified carrier fallback. The agreement has since changed. Context Graph preserves the earlier policy, marks it as superseded, and links the current confirmed-capacity requirement to clause 7b, so useful history does not become stale advice. ## Workflow ### Recognize the superseded policy - The earlier Horizon fallback policy remains inspectable. Its status and replacement link explain why it should no longer guide the decision. ### Follow the current requirement - Clause 7b requires confirmed carrier capacity. A weekly roster by itself does not meet the current agreement. ### Inspect the cited passage - Open the source wording beside the stored observation. The next reviewer can understand the basis for the requirement without rebuilding the investigation. ## Next steps Choose a recurring decision and the evidence behind it. Define how the team will review, update, and recognize superseded knowledge. - [Contact sales](https://www.trypascal.io/contact) - [Pascal Work](https://www.trypascal.io/solutions/pascal-work) --- # Pascal Models Source: https://www.trypascal.io/platform/models A better score is only the beginning. Connect prediction objectives, evaluation results, and release decisions. Give each model version a clear case for further study or use in the operation. ## Capabilities ### Start with the decision Specify what to predict, for whom, how far ahead, and what acceptable performance means. Keep the target, risk, and review requirements attached to the objective revision. ### Fix the data behind each run Connect training datasets and feature releases to the exact inputs used. Review freshness and coverage before a training or prediction command proceeds. ### Compare the tradeoffs Inspect training trials, pin an explicit baseline, and compare measured quality and operational metrics. Keep the decision to select, reject, or continue separate from the comparison view. ### Evaluate before release Review results on a fixed sample, including relevant slices, guardrails, and insufficient-data outcomes. Carry the evaluation into the review of a model version. ### Deliver an exact version Publish an immutable model release for batch or online delivery. Follow deployment, canary, promotion, and rollback through the serving controls. ### Keep learning from the operation Connect observations and labels to monitoring. Investigate incidents and propose evaluation, annotation, rollback, or retraining with an authorized next action. ## Connected context Connect data and features to training candidates and evaluation results. Model Registry and Serving handle releases and predictions; Lab and monitoring bring feedback into the next review. - Modeling objectives, revision history, targets, metrics, and guardrails - Dataset and feature releases, training jobs, trials, and evaluation results - Model releases, batch predictions, deployments, monitor windows, and feedback ## Controls and permissions Each step retains its own inputs, review, and result. The walkthrough demonstrates candidate comparison and a decision to continue studying. Hosted language-model providers and routing are managed separately in AI Models. ## Example Meridian compares three candidates for predicting which shipments will miss the 21:00 cutoff. Trial 3 improves the overall score, but hazardous-load recall falls below the 90% minimum. Maya records Continue study with a reason to improve recall before proposing a release. ## Workflow ### Define the objective - Keep the decision, training inputs and guardrails together. Fix the criteria that will make a prediction useful to the operation. ### Compare candidates - Inspect the baseline, evaluation results and slice performance. Record whether to select, reject or continue studying the candidate. ### Plan its operating life - Take an evaluated version through release and the qualified delivery path. Monitor the result against the decision it is intended to support. ## Next steps Bring one model objective, its baseline, and the guardrails that matter in your operation. Define what a candidate must demonstrate before release. - [Contact sales](https://www.trypascal.io/contact) - [Logistics operating system](https://www.trypascal.io/solutions/logistics) --- # Pascal Work Surfaces Source: https://www.trypascal.io/platform/work-surfaces Build software around your business. Create internal applications on your business data, objects, and actions. Bring the queue, context, and next decision into one place for your team. ## Capabilities ### Build around the operation Author internal interfaces with React routes, scoped CSS, and Pascal components. Choose a layout for the records, context, and actions the team needs. ### Connect to workspace resources Declare the application’s data and action bindings in the project. Use generated handles to connect the interface to those resources. ### Present useful data states Use native tables and status components to show the records available, their freshness, selection, and the context behind a result. ### Work with Codex on the change Prepare source changes in a Code Task. Inspect the files and diff before applying the working copy to the project. ### Preview the applied project Open the project preview to review the interface after Apply. Keep it distinct from the task’s working copy and the released application. ### Follow the project to release Build from the project and use its release workflow to make the application available. Connected data and actions retain their current workspace permissions. ## Connected context Build on records from Data and Ontology, processes from Compass, and reusable functions from Forge. Keep implementation and review connected to the team in Workrooms. - React routes, styles, and project configuration - Declared data, process, and action bindings - Code Tasks, applied source, previews, and releases ## Controls and permissions Review the source, preview the application, and follow the build through release. Connected data and actions retain their own permissions. Releasing the interface does not approve the business decisions made through it. ## Example Meridian needs a work queue that connects requirements, implementation, and reviews. Factory Control gives the team that application on Pascal’s existing objects and workflows. The active application can be used while the lithium policy change follows its own approval path. ## Workflow ### Build on the business model - Factory Control uses native components and project-local bindings to connect work items, requirements, and reviews. ### Inspect the working preview - Open the interface and follow a lithium work item before applying the source. The preview lets the team review how the work fits together. ### Use the reviewed application - Factory Control 1.0.0 is active after engineering acceptance and explicit activation. Its three queue items remain available after reload. ### Keep operating decisions explicit - The linked Logistics Exception Desk preview still shows pending Compliance. An application release does not approve a change to shipment policy. ## Next steps Choose one user, one recurring workflow, and the business objects and actions the application should bring together. - [Contact sales](https://www.trypascal.io/contact) - [Logistics](https://www.trypascal.io/solutions/logistics) --- # Pascal Developer Platform Source: https://www.trypascal.io/platform/developer-platform Build on the business. Ship what it needs. Create applications, functions, and integrations using Pascal’s business objects and APIs. Keep source, checks, review, and release connected. ## Capabilities ### Build internal interfaces in React Author Work Surfaces with ordinary TSX routes, scoped CSS, and Pascal UI components. Static project configuration declares the resources the interface uses. ### Connect the interface to the operation Generated bindings connect a Work Surface to its declared data, actions, and agents. Keep those references with the project that uses them. ### Package reusable business logic Use Forge for a calculation or business function. Inspect its code, test it, and review its version before choosing where it is activated. ### Integrate through the TypeScript SDK Configure an API endpoint, access token, and workspace for a service. Use the SDK’s supported resource contracts and the authenticated Developer Portal for the available API surface. ### Inspect changes before applying them Work with Codex in a Code Task. Files and Changes show the working copy. Apply transfers the reviewed change to the project; release remains a separate decision. ### Keep access specific to the work Choose credentials and permissions for the service or person making a request. A consequential function follows the operation’s authorization and review path. ## Connected context Build internal interfaces with Work Surfaces, reusable functions with Forge, and system connections with Integrations. Use Workrooms to keep the implementation and review with the team. - React source and static project configuration - Typed bindings and supported SDK resources - Code Tasks, builds, function versions, and releases ## Controls and permissions Use the API of the product responsible for each resource. Workspace credentials and current permissions govern every request. Applying source, activating a function, and completing a business action remain separate steps. ## Example A coding Task builds Factory Control with React routes, native components, and project-local bindings. The developer reviews the diff, checks, and working preview before applying the source. Engineering acceptance and explicit activation bring the application into use, with the operating policy review still tracked separately. ## Workflow ### Start from the operating project - The Factory Control project connects the application to its requirements and intended users. The implementation has a clear business purpose. ### Inspect the source change - Open the Code Task’s files and diff. Review the native components and project-local bindings alongside the checks and working-copy preview. ### Follow the release review - The application review applies to its exact source and build. The separate lithium operating change still needs Operations and Compliance. ## Next steps Bring an application, function, or integration idea. Identify its product APIs, permissions, and the path from local implementation to reviewed release. - [Contact sales](https://www.trypascal.io/contact) - [Software delivery](https://www.trypascal.io/solutions/software-factory) --- # Pascal Forge Source: https://www.trypascal.io/platform/forge One business rule. Every caller aligned. Package shared logic as typed functions. Test the cases that matter, review a version, and make it available to the people, agents, and workflows that need it. ## Capabilities ### Define the contract Name each function, define its inputs and outputs, and declare its effects and supported surfaces. ### Review the source Work with Codex in a Code Task. Inspect Files and Changes before applying reviewed source to the package. ### Inspect the build Follow validation, tests, and packaging. Inspect the result before choosing which version to release. ### Choose an activation Select the functions, versions, callers, and surfaces. High-risk functions require an explicit risk acknowledgement. ### Run calculations and transformations Use declared functions for operational calculations, row mappings, table transformations, and business-object actions. ### Follow the result Inspect function runs and redacted output. Follow a consequential action through review and confirmation from the system it changes. ## Connected context Reuse activated functions in Agents, Workflows, Data Pipelines, and Ontology actions. Keep the source, tests, builds, and release history together in the development workflow. - Package source and function contracts - Builds, tests, and package versions - Activations and function runs ## Controls and permissions Choose which version each caller can use. When a function changes a record or external system, that action still requires current permission and confirmation. Activating the function does not activate every process that refers to it. ## Example The Workflow draft and the Shipment action preview need the same tendering rule. Both use evaluateTenderReadiness 0.4.0 after its three behavior checks and activation review. A passing missing-approval test confirms the expected hold. The function supplies the decision; it does not book a carrier or tender a shipment. ## Workflow ### Make the contract explicit - The function accepts a shipment, telemetry, and Compliance evidence. It returns a readiness decision with reason codes; missing approval produces a hold. ### Test the outcomes that matter - Approved, Stale telemetry, and Missing approval all match their expected results. Inspect the immutable build and the tests behind version 0.4.0. ### Activate the version for its callers - After review of the exact plan, version 0.4.0 is activated for the Workflow and Ontology action previews. The function evaluates readiness; the running tendering process remains v12. ## Next steps Choose a calculation or decision several callers need. Define its inputs, outputs, expected failures, and who can approve its use. - [Contact sales](https://www.trypascal.io/contact) - [Software Factory](https://www.trypascal.io/solutions/software-factory) --- # Pascal Governance Source: https://www.trypascal.io/platform/governance Clear permissions. Accountable action. Set who can access data, propose a change, and approve it. Keep the permission, decision, and confirmed result with the work. ## Capabilities ### Scope what each person can access Manage membership, teams, roles, and grants. Apply the relevant workspace, record, and field restrictions to the data people and agents use. ### Check authority at the moment of action Evaluate the current policy when a tool or operation is invoked. Keep a research task distinct from permission to change an external system. ### Bring the right person into the decision Route consequential changes with the proposal and its evidence. Preserve the reviewer’s decision with the action it authorizes. ### Bound delegated work Define which tools, data, resources, and effects an agent may use. Keep the scope of a task and the limits of its authority explicit. ### Trace the action through its outcome Connect the request, policy decision, approval, and activity record. Inspect the result returned by the system responsible for the change. ### Review and maintain access over time Inspect grants and policy decisions, review who still needs access, and handle revocation and retention through their managed workflows. ## Connected context Apply identity, access rules, and reviews across Pascal. Keep the proposal, approval, and result connected as work passes between people, agents, and external systems. - People, teams, roles, and access grants - Policies, reviews, and approval decisions - Audit history, action receipts, and retention ## Controls and permissions Approval permits an action; the responsible system confirms its result. If the outcome is unknown, check what happened before retrying. Revoking access prevents new effects while preserving the record of work already performed. ## Example An operator approves 14 eligible reroutes after reviewing the proposal. The Task retains the confirmed result and follow-up work. Three lithium shipments remain held, and a proposed process change still awaits Operations and Compliance. Each decision covers the work it actually authorizes. ## Workflow ### Review the proposed action - The Task requests approval for the eligible reroutes. The proposal states its scope and retains the three hazardous-load holds. ### Inspect the confirmed result - The recorded action returns confirmation. The team can distinguish the decision to allow the action from the result of carrying it out. ### Keep unresolved work visible - Confirmation covers the approved reroutes. The remaining lithium loads still require their own Compliance decision before they can move. ## Next steps Choose an action that matters. Identify who can request it, who must approve it, and which system will confirm the result. - [Contact sales](https://www.trypascal.io/contact) - [Pascal Work](https://www.trypascal.io/solutions/pascal-work) --- # Pascal Work Source: https://www.trypascal.io/solutions/pascal-work Less catching up. More moving forward. Bring scattered records, team knowledge, and AI agents into one shared workspace. Understand the problem, agree on the next move, and give every handoff a clear owner. ## Who this is for For operations, customer success, and cross-functional teams ## The risk is in the CRM. The reason is somewhere else. Usage shows what changed. Support knows what broke. The account team knows what was promised. When a customer is at risk, those facts need to come together quickly. Pascal connects the records and the people, so the team can move from diagnosis to a response everyone understands. Northstar renews in 45 days. Usage has fallen and the customer’s champion has changed. The account team needs to understand the cause before choosing its response. Account notes, usage findings, and the open support case come together in one Workroom. The analytics team has lost access; the other three teams are stable. The account team asks Pascal to turn that diagnosis into a recovery plan and a message for the new champion. ## Workflow ### Define State: source. Identify the customers, cases, commitments, and responsibilities that define the operation. ### Connect State: source. Connect the records, documents, events, and conversations the team needs to understand a case. ### Observe State: source. Keep the current work and its missing information visible to the people responsible. ### Reason State: proposal. Compare possible responses against the facts, constraints, and desired result. ### Govern State: approval. Check access, define the proposed action, and bring the right decisions to a human reviewer. ### Execute State: effect. Assign and carry out approved work through the systems that own the relevant records. ### Evolve State: receipt. Review what happened and use the result to improve the next version of the process. ## Result and action boundary The team leaves with three concrete assignments: Priya restores analytics access, Alex follows the support case through customer confirmation, and Maya prepares the champion conversation. The plan and customer draft stay together in the Workroom, ready for the team to review. The customer message remains a draft. Commercial terms are unchanged, and nothing has been sent or written to the CRM. The account team still needs to verify that access and adoption recover. ## Start and expand Choose a recurring handoff that spans several tools. Bring the account or case, its source records, and the people who need to act. Agree on what they can authorize and how you will confirm the result. Start with account recovery, then apply the same approach to service escalations and cross-team approvals. Reuse the account context and working relationships; define the decision owner and completion check for each new workflow. ## Related products - [Ontology](https://www.trypascal.io/platform/ontology) - [Workflows](https://www.trypascal.io/platform/workflows) - [Agent Tasks](https://www.trypascal.io/platform/agents) - [Workrooms](https://www.trypascal.io/platform/workrooms) - [Context Graph](https://www.trypascal.io/platform/context-graph) - [Work Surfaces](https://www.trypascal.io/platform/work-surfaces) ## Next step [Discuss your workflow](https://www.trypascal.io/contact) --- # Logistics Source: https://www.trypascal.io/solutions/logistics Keep the promise when the plan breaks. Connect a disruption to the shipments and customer commitments it threatens. Compare recovery options and coordinate the next move across your team and carriers. ## Who this is for For supply chain leaders, dispatch, and network operations ## A disruption moves faster than a handoff. The carrier notice lands in an inbox. Shipment commitments sit in the transport system. Fallback terms live in an agreement. By the time someone assembles the picture, the best capacity may be gone. Pascal brings the disruption, commitments, and available options into the same decision. Horizon Freight files for bankruptcy with 42 active shipments on its lanes. Seventeen face a high risk of missing the 21:00 UTC cutoff. Meridian’s operations team needs a recovery decision while there is still time to act. Follow the affected shipments into their source records and fallback agreement. Compare available capacity, review the exact reroute, and approve the 14 eligible shipments. Three hazardous lithium loads stay on hold for Compliance. ## Workflow ### Detect State: source. Bring the closure, delay, capacity change, or other disruption into the operation. ### Connect State: source. Link the signal to affected shipments, orders, customer commitments, and responsible teams. ### Predict State: source. Estimate which commitments are at risk and when recovery options will expire. ### Decide State: proposal. Compare feasible responses against capacity, service, cost, and safety constraints. ### Authorize State: approval. Give the reviewer the proposed route, affected loads, exceptions, and decision scope. ### Act State: effect. Carry out the approved response through the transportation and customer systems involved. ### Adapt State: receipt. Check the resulting records and physical progress, then keep unresolved exceptions in view. ## Result and action boundary The example ends with 14 recorded reroutes and completed carrier and customs follow-ups. Three hazardous loads remain held for Compliance. The next job is to track pickup and delivery events: zero new breaches is still a projection, not an observed service result. The operator approves the specific eligible reroutes once. That decision does not release the three hazardous loads or override their compliance requirements. A projected service result remains a forecast until the relevant shipment events confirm it. ## Start and expand Begin with one exception type, such as a missed pickup or corridor closure. Connect the source notice, shipments, commitments, route constraints, approval owners, and the system records that will confirm recovery. Extend from one carrier failure to missed pickups, capacity shortfalls, or customs holds. Reuse shipment and commitment context, then add the constraints, partner handoffs, and confirmation events that each exception requires. ## Related products - [Ontology](https://www.trypascal.io/platform/ontology) - [Integrations](https://www.trypascal.io/platform/integrations) - [Atlas](https://www.trypascal.io/platform/atlas) - [Compass](https://www.trypascal.io/platform/compass) - [Agent Tasks](https://www.trypascal.io/platform/agents) - [Workflows](https://www.trypascal.io/platform/workflows) - [Context Graph](https://www.trypascal.io/platform/context-graph) - [Work Surfaces](https://www.trypascal.io/platform/work-surfaces) ## Next step [Discuss your workflow](https://www.trypascal.io/contact) --- # Private equity Source: https://www.trypascal.io/solutions/private-equity Carry the investment thesis into the work. Keep diligence findings, investment assumptions, and operating priorities connected. Give each claim a source, each open question an owner, and each initiative a basis for review. ## Who this is for For deal teams, operating partners, and portfolio leaders ## The thesis should survive the handoff. An investment conclusion depends on a model version, a diligence answer, and assumptions about the business. When those pieces separate, the next team has to reconstruct the case. Pascal keeps the claim, evidence, and open work together from deal preparation to the initiatives management chooses to pursue. Tomorrow’s deal call needs a consistent account of operating performance. The deck, model, diligence tracker, and legal notes tell different parts of the story. In the deal Workroom, a revenue bridge discrepancy, five open diligence questions, and two disclosure holds become a preparation brief. Pascal organizes the questions for the internal team and prepares a separate client draft, keeping each audience’s information distinct. ## Workflow ### Underwrite State: source. Connect investment claims to their sources, assumptions, sensitivities, and open questions. ### Seal State: source. Record the approved investment decision, source revisions, conditions, and disclosure limits. ### Accept State: approval. Let company management review each proposed handoff and decide what it will own. ### Rebuild State: proposal. Turn accepted priorities into defined initiatives, required software changes, and named responsibilities. ### Operate State: effect. Run approved initiatives under company access rules, review requirements, and operating limits. ### Realize State: receipt. Ask company finance to distinguish observed improvement from validated financial benefit. ### Compound State: receipt. Carry approved lessons and reusable practices into the next initiative while preserving company boundaries. ## Result and action boundary The team has an internal agenda with five questions and named owners, plus a client draft that excludes the two restricted disclosures. Reviewers can resolve the gaps before the call and decide what is ready to share. Both briefs remain drafts. A prepared brief is not an approved disclosure. After close, portfolio-company management remains responsible for operating decisions and finance remains responsible for validating benefits. Sponsor oversight does not grant direct authority over company systems. ## Start and expand Begin with one investment claim or value-creation initiative. Agree on its sources, assumptions, company owner, permitted actions, and the operating and financial observations that will determine whether it worked. After diligence, connect an accepted investment claim to a company-owned initiative. Carry forward the source and assumptions, establish the operating baseline, and review the result with management and Finance. Each portfolio company keeps its own access and decision boundaries. ## Related products - [Bedrock](https://www.trypascal.io/platform/bedrock) - [Ontology](https://www.trypascal.io/platform/ontology) - [Workrooms](https://www.trypascal.io/platform/workrooms) - [Context Graph](https://www.trypascal.io/platform/context-graph) - [Compass](https://www.trypascal.io/platform/compass) - [Atlas](https://www.trypascal.io/platform/atlas) - [Workflows](https://www.trypascal.io/platform/workflows) - [Work Surfaces](https://www.trypascal.io/platform/work-surfaces) ## Next step [Discuss your workflow](https://www.trypascal.io/contact) --- # Software Factory Source: https://www.trypascal.io/solutions/software-factory Build the software your operation needs next. Give coding agents the business context behind the request. Carry requirements into a working application, with the source, checks, review, and release connected. ## Who this is for For engineering, platform, and business systems teams ## The hard part starts before the first line of code. The operating team knows what needs to change. Engineering needs the business objects, permissions, edge cases, and acceptance criteria behind the request. Pascal keeps that context with the build, so reviewers can judge whether the software solves the problem that started it. A new port lithium rule creates work for Meridian’s operations and engineering teams. They need a place to connect eight requirements, the implementation, and the people who will review the change. The team builds Factory Control: an application that brings the work queue, requirements, coding Tasks, and reviews together. The walkthrough follows it from the initial request through a working preview, engineering review, and release, then opens the first item in the running application. ## Workflow ### Frame State: source. Define the user, current behavior, intended outcome, constraints, and acceptance checks. ### Model State: source. Identify the business objects, data, actions, permissions, and process states the change must respect. ### Compose State: proposal. Choose the existing company capabilities the application can use and the new components it needs. ### Produce State: proposal. Give people and coding agents the relevant context to prepare source changes, tests, and a reviewable proposal. ### Qualify State: approval. Run the checks, inspect the preview, and collect the required business and engineering reviews for this version. ### Release State: effect. Let the authorized owner publish the approved artifact with its rollout and recovery plan. ### Learn State: receipt. Review software health and operating results, then turn the findings into the next defined change. ## Result and action boundary Factory Control 1.0.0 is active, with three queue items linked to their requirements, implementation Tasks, and reviews. Reloading preserves that working state. The team can use the application while Maya Chen and Jordan Lee review the separate lithium operating change. Engineering acceptance and application activation apply to the exact Factory Control source and build. They do not approve lithium tendering. Operations and Compliance must review that operating change separately; current shipment holds and policy remain in force. ## Start and expand Choose one bounded software change with an identifiable operating user. Define the current behavior, the intended result, relevant business objects and permissions, acceptance checks, and the person who can authorize release. Begin with an exception desk, approval queue, or review workspace. Build the next change on the same business objects and permissions, with its own requirements, checks, and release decision. Keep the running application connected to the operating feedback that prompted the work. ## Related products - [Bedrock](https://www.trypascal.io/platform/bedrock) - [Ontology](https://www.trypascal.io/platform/ontology) - [Work Surfaces](https://www.trypascal.io/platform/work-surfaces) - [Developer Platform](https://www.trypascal.io/platform/developer-platform) - [Agent Tasks](https://www.trypascal.io/platform/agents) - [Forge](https://www.trypascal.io/platform/forge) - [Workflows](https://www.trypascal.io/platform/workflows) - [Context Graph](https://www.trypascal.io/platform/context-graph) - [Governance](https://www.trypascal.io/platform/governance) ## Next step [Discuss your workflow](https://www.trypascal.io/contact)