# 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)