rigwright.

The workshop / An application preview

Put the machinery
to useful work.

Choose a system. Work with it in your environment. See the changes, checks and materials that make it yours.

Design preview

Explore the proposed application with illustrative data. Switch screens and inspect a sample blueprint. There is no connected backend, live run, account or purchasable package here.

Workshop / LibraryINTERACTIVE CONCEPT
YOUR STARTING POINT

Choose useful software.

Know what it does. See what comes with it.

Sample catalogue
APPLICATION STARTER · CONCEPT

Request-and-approval desk

Turn incoming business requests into clear actions, approvals and a traceable decision history.

RequestsApproval rulesDecision history

A system for the work.

Use a configured application in its supported environment. This example shows incoming requests and the rules that route them.

Operating options and availability would be defined per release.

The implementation, and how to change it.

Source, specifications, schemas, agent context and checks. Bring a named release into your business and adapt it with your agent.

Commercial rights, support and pricing are still undecided.
Software change factoryA recipe for the engineering work
Independent primitivesTake only the parts you need
EXAMPLE PROJECT / REQUEST DESK

A starting point. Made yours.

The application and the change you want to make.

Sample records
BASELINERequest desk
WORKSPACEExample business
STATUSIllustrative project
Incoming requests3 sample records
REQ 01
Equipment purchaseOperations · $7,250
Awaiting approval
REQ 02
Supplier onboardingProcurement · Documents attached
In review
REQ 03
Research subscriptionEngineering · $840
Recorded
A BUSINESS-SPECIFIC CHANGE
Require a second approval for requests above a configurable amount.

The proposed factory would update the behavior, application and acceptance checks together. The day-to-day request desk is the software it changes.

EXAMPLE CHANGE / TWO-PERSON APPROVAL

See the work behind the result.

An illustrative run, paused at a human decision.

Example decision
  1. 01
    Specify the behavior

    Second approval above $5,000. Different approvers required.

    Example specification
  2. 02
    Change the application

    Approval policy, decision record and request interface.

    Example change set
  3. 03
    Check the behavior

    Boundary amounts, duplicate approvers and missing permission.

    Illustrative checks · not executed
  4. 04
    Review a known revision

    A person inspects the change and its evidence before accepting it.

    Decision would be required
ILLUSTRATIVE ADOPTION MATERIALS

More than the generated code.

The system, its context, and the means to check a change.

Sample package
WHAT A RELEASE COULD CONTAIN
  • Application source
  • Behavior specification
  • Request & approval schemas
  • Agent context & instructions
  • Checks & sample records
  • Setup & recovery guide
  • Rights & support terms
SAMPLE BLUEPRINTNon-executable
01 / INPUTRequest + amount
02 / RULEAbove threshold?Require two different approvers
03 / OUTPUTRecorded decision
CHECKS Boundary amounts · Permissions · Duplicate approvers
Take a closer look.

Download an illustrative, non-executable blueprint. Application source and commercial terms would belong to a qualified release.

Download sample JSON
PLANNED ACCESS PATHS

Choose how you work.

A client is the interface. An executor does the work.

Not connected
FIRST-PARTY NATIVE WORKSPACE

Novalis

Terminals, agent sessions and project tools. The planned integration would bring factory activity, artifacts and decisions into the workspace.

In development
CLI / API / MCP

Your existing coding agent

Inspect a package, make permitted changes and return evidence. Supported clients, authentication and tool access still need qualification.

Planned
WEB INTERFACE

The workshop

A shared view of packages, projects, runs and decisions, explored here with a sample business workflow.

Concept

Local, customer-run and hosted execution have different permissions and costs. A personal coding-agent subscription does not automatically fund hosted API calls.

Illustrative data throughoutExplore the proposed experience.

The proposed journey

From useful software
to your own system.

A business application handles everyday requests. A software factory makes a change to that application. The two have different jobs.

01 / CHOOSE

Understand the starting point.

Inspect the outcome, dependencies, readiness and actual contents of a named release.

02 / USE OR ADOPT

Decide what you need.

Use its supported behavior, or obtain the source and engineering materials under defined rights.

03 / CHANGE

Work with your agent.

Make a supported change in your workspace. Keep the specification and acceptance checks with it.

04 / INSPECT

Keep the result and its evidence.

See what ran, what failed and what was accepted. An approval does not silently mean a deployment.

Planned access paths

The workspace
is your choice.

These are integration directions. Actual client support and operating requirements need qualification before a release.

NOVALIS

Native work, in context.

Our first-party workspace brings terminals, agents and project tools together. Factory integration would expose work, artifacts and human decisions alongside them.

EXTERNAL AGENTS

Use the agent you already work with.

CLI, API and MCP interfaces would let supported coding agents inspect packages and perform permitted operations. Access, execution resources and billing remain separate choices.

The first release will state which paths are supported.Explore the product families ↗