What is SYSTEM1

SYSTEM1 develops custom decision models and the tools that turn their decisions into useful behavior. A business describes a capability it wants inside its software. The project develops that capability through tool design, training data, model training, evaluation and deployment.

Consider a studio that wants to give its artists a new instrument: direct a scene while it plays. The artist should control a group’s behavior, one character’s motive or a local exception while the existing scene continues.

This article follows that proposed project through the service. The scene is a worked design example. The final section distinguishes the implemented service from the work this project would require.

1. Describe the interaction you want to create

A reception fills the studio’s 3D editor. Guests talk, staff serve drinks, and a couple argue by a window. The studio already has its characters, animation assets and renderer. It wants a different way to direct their behavior.

123

1. The managerA current concern for the server.
2. The serverA tray delivery already in progress.
3. The coupleAn exchange the artist wants to preserve.

The artist gives a direction:

The lights fail, but nobody should admit that the evening is going wrong. Keep the couple by the window in their argument.

The staff try to maintain service. Guests respond to what they notice around them. One person continues a story. Another watches the staff. Someone near the service door seeks an explanation. The couple’s argument continues.

The artist selects one server:

They are worried about losing this job, not the lights. Let them finish the service before they check what happened.

The lights return. Guests relax, but the server still watches the manager. The server completes the service before the request for reassurance. The server’s concern persists because its cause differs from the guests’ concern.

Now the artist moves the manager across the room. The server responds to the manager’s actual position. The artist can retain that performance and change another group’s response. The scene continues through these edits.

The useful control is more precise than a global mood setting. The artist can change why someone acts, where a direction applies and which existing action must continue. Later events expose whether the software understood that correction.

That interaction gives the project its requirements. The studio supplies examples of good and bad performances, its behavior vocabulary, existing engine interfaces and supported actions. It also identifies what artists need to inspect, override and preserve.

The studio can commission models for existing tools or ask SYSTEM1 to develop both. The service’s purpose is to make this entire development process a manageable business project.

2. Define the decisions that the interaction needs

A decision task has an input, a question and a defined set of possible answers. Its input must contain the facts that distinguish those answers.

For the server, one task concerns what an event means for the current goal. Another concerns the next activity. Those choices remain separate: the lights can work again while the concern about employment persists.

Decision	Relevant input	Example outcomes
What deserves attention?	Observed events, current activity and the artist’s direction.	Continue, observe, seek more context or interrupt at a permitted point.
What does the event threaten?	The character’s current concern and relevant history.	The service task, public appearance, a personal goal, several goals or no established concern.
What can the character do next?	The interpretation, current commitment and available actions.	Finish service, seek reassurance, request help, investigate or retain the current activity.
Can an interaction proceed?	The participants, their commitments and the shared object.	Accept, defer, choose another participant or report an unresolved requirement.

These are proposed task boundaries. The project refines them with the studio. Some questions can share a model and one input. Others need separate models because they use different context or serve different tasks.

The same event must support different answers. A guest sees a lighting fault. A server interprets it against a warning from the manager. A technician knows that a planned test is under way. Supplying every character with the same complete scene description would erase those differences.

An explicit artistic direction takes precedence over an inferred motive. If the artist assigns concern about employment, the absence of an earlier warning does not erase that direction. Before the correction, a model needs evidence to infer that concern. After it, the concern is part of the authored scene. The tool must retain which kind of statement it holds.

The studio accepts the proposed task boundaries and tool vocabulary through concrete cases before a large training run. A wrong answer can reveal a missing distinction, a missing observation or an unclear rule. More examples cannot repair information that the application never supplies.

3. Build tools at the level of the work

The scene needs more than functions to move an object or set an animation. It needs operations that preserve the meaning of an artistic direction.

A direction tool records the affected characters, their concern, preserved activities and the conditions that end the direction. An observation tool supplies what a character can see or hear. An activity tool records the current task and its permitted interruption points.

An interaction tool coordinates shared work. If one server passes a tray to another, both participants and the tray must be available. A model can propose that handoff. The tool must check and execute the transfer.

Some work belongs in existing systems. Geometry determines whether a wall blocks the manager. Navigation computes a path. An animation controller realizes a gaze or movement over time. Learned decisions interpret the studio’s contextual distinctions and choose useful supported actions.

This division has substantial prior art. Improv separated behavior and animation, supported coordinated actors and exposed control at different levels of abstraction in 1996. The new commission does not need to invent those foundations. It needs to turn the studio’s vocabulary and examples into a usable instrument. Perlin and Goldberg, Improv: A System for Scripting Interactive Actors in Virtual Worlds

Existing execution tools can help. SmartBody, for example, translates behavior descriptions into movement, gaze, gesture and object interaction. A commissioned tool can connect learned choices to such an engine. It must still define the particular observations, commitments and operations that its artists need. USC Institute for Creative Technologies, About SmartBody

4. Create data against those exact tools

The training examples must represent situations that the deployed instrument will encounter. A sentence and an emotion label are insufficient for this project.

An example can include the artist’s direction, the character’s observations, relevant history, an activity in progress and available operations. Its targets describe the decisions the system should make. Tool results establish which operations can actually succeed.

The data process creates consequential variations:

• Restore the lights while the manager’s warning remains relevant.
• Move the manager and retain the server’s concern.
• Keep the same direction but change whether the tray transfer is complete.
• Hide the manager behind a wall and remove any other source of location knowledge.
• Change the wording of a direction while its meaning stays the same.
• Before the artist assigns the concern, remove the earlier warning. The model must not invent a fear of dismissal.
• After the artist assigns the concern, remove that warning. The explicit direction must remain in force.
• Ask for an action that the current animation and interaction tools cannot perform.

Some changes should preserve an answer. Others should change it. CheckList formalizes this distinction through capability tests, invariance tests and tests for an expected change in behavior. The project needs those tests for its own vocabulary and operations. Ribeiro and colleagues, Beyond Accuracy: Behavioral Testing of NLP Models with CheckList

Synthetic generation can extend the studio’s examples across roles, directions and scene states. It does not establish correctness by itself. Self-Instruct’s quality analysis finds incorrect outputs even after its filtering process. The requested label and the generated example need separate review. Wang and colleagues, Self-Instruct: Aligning Language Models with Self-Generated Instructions

Mechanical checks can verify identities, visibility, object availability and valid operations. Studio review must assess whether the behavior conveys the intended performance. A second model can help review examples, but model agreement does not establish artistic quality.

Related examples stay in one data group. A scene, its paraphrases and its altered states must not appear on both sides of the training/test boundary.

The business reviews the generated examples in its project. It can inspect the input, target decisions, source group and split. A coverage report should identify missing situations, not simply display a large row count.

5. Train the custom models

A decision base is the base model and its method for defined decision tasks. SYSTEM1 supplies the current state, a question and descriptions of the permitted outcomes. The model scores those outcomes directly. The application can use the result without a generated paragraph.

Customer training adapts that model to the project’s distinctions and tools. The current task-training path uses low-rank adaptation, or LoRA. It retains the base weights and learns smaller matrices that represent an update. The update can later merge into the deployed model. Hu and colleagues, LoRA: Low-Rank Adaptation of Large Language Models, Sections 4.1–4.2

For the scene project, one model could learn contextual event interpretation. Another could learn activity selection from the interpreted state and available operations. Their training inputs must match what the deployed graph supplies. Geometry and object ownership need exact tools rather than language-model training.

The project pins its dataset, task definition, base checkpoint and training configuration. Development examples guide candidate selection. The service retains the starting candidate if adaptation does not justify a replacement. A completed optimizer run alone does not establish an improved model.

There are two distinct levels of model development. General adaptation trains a custom decision base across many tasks. Customer adaptation then specializes that base for a particular domain and its tools. General adaptation can teach common decision behavior across different questions, answer menus and context rules.

The active implementation currently uses pinned stock base weights for task training. A custom general base needs evidence that it improves later customer adaptation before it replaces those weights. That comparison must use equivalent customer data and training budgets. The current path already supports real customer-specific adaptation of the pinned base.

The project exposes the training job, its progress, configuration, data and evaluations. A business can follow actual runs and compare results on its own cases. The scene instrument ultimately needs the complete set of tested components, not one model with a broad name.

6. Connect parallel decisions through real dependencies

A lighting change can affect many characters at once. Their local event assessments can run in parallel. Each activity choice then uses the relevant interpretation. A proposed interaction adds a dependency on another participant and any shared object.

When that interaction completes, it creates new observations. Nearby characters may respond. Unrelated people can continue their existing work throughout this sequence.

That is the purpose of a multilayer decision architecture. Each layer answers a useful question at the point where its inputs become available. The output can become context for another model or an instruction to a tool. The graph can contain branches, joins and continuing feedback.

Selected history matters. Generative Agents uses observations, memory retrieval, reflection and plans to maintain behavior over time. Its authors show why individually plausible actions can form an incoherent sequence. The scene project needs the same care about context, even when repeated decisions use specialized models rather than a large generative request. Park and colleagues, Generative Agents: Interactive Simulacra of Human Behavior, Sections 4.1–4.3

The renderer has a separate schedule. A character’s walk continues between model decisions. A model request is useful when a relevant event occurs or an activity reaches a choice point. It is not necessary for each rendered frame.

Specialized motion research illustrates that separation. MotionPersona produces short motion blocks and revises queued motion when controls change. Its results concern a defined locomotion catalogue, not arbitrary acting. The useful architectural point is that a continuous controller can execute movement while another process revises higher-level choices. Shi and colleagues, MotionPersona: Real-Time Locomotion Control across Personas, Bodies, and Styles, Section 5.6 and Appendix F

The runtime must also respect the artist’s latest direction. A response to an earlier instruction cannot replace a newer correction merely because it arrives later. Tool operations check the relevant scene and direction versions before they act. Unaffected activities retain their state.

This design makes latency part of the interaction. Measure context preparation, queue time, inference, tool execution and the visible response. Batch compatible decisions where useful. A fast isolated model does not establish that a crowded interactive scene will respond in time.

7. Test the resulting behavior

A model can select an allowed answer and still produce the wrong scene. The project therefore evaluates the complete path from an observation to its visible consequence.

Suppose an observation component wrongly reports that the server sees the manager. The activity model receives that report and chooses an otherwise reasonable action. A test that always supplies correct observations will miss the resulting failure.

The evaluation must use actual upstream outputs, including errors and unresolved results. It must also vary conditions while work is in progress.

Test	What the complete system must preserve
The lights return.	The server’s separate concern persists while guests respond to the restored lighting.
The manager moves out of view.	The server cannot acquire unexplained knowledge of the new position.
A tray transfer is in progress.	A new direction respects the permitted interruption point.
Another participant becomes unavailable.	The proposed interaction resolves or changes without freezing unrelated actors.
The artist corrects a direction during inference.	The earlier response cannot overwrite the correction.
The warning disappears after the artist assigns the concern.	The authored direction persists. A missing observation does not cancel it.
The artist requests an unsupported action.	The instrument identifies the missing capability and offers a useful next step.

Confidence has its own evaluation. Calibration adjusts confidence against correctness on separate examples. It cannot supply missing context or repair a wrong observation. The project must measure both errors among automatic decisions and how often the instrument asks the artist for help. Guo and colleagues, On Calibration of Modern Neural Networks

A locked final test uses source groups that did not guide training, model selection or confidence adjustment. The studio reviews the candidate against the previous version on these cases and authorizes the compared release. Human performance review remains necessary. Valid tool calls and good classification scores cannot establish that the director obtained the intended scene.

8. Embed the capability in the studio’s software

The release contains the selected model versions, decision definitions, domain tools, execution graph and evaluation evidence. A validated OpenAPI description defines callable inputs, outputs and failure results.

The model server runs the trained decisions. The tool container supplies the domain code and its dependencies. The studio’s editor sends relevant state through that interface and applies validated results through its engine adapter.

A sandbox can start when the tools are needed. An active editing session can reuse its running service. Cold startup belongs in the first-response measurement. Per-decision latency describes a different part of the experience. Resource limits, concurrent work and session duration need explicit budgets.

The tool contract also defines recovery. If the editor loses a response to a completed tray transfer, a repeated request must recover that result rather than transfer the tray twice. If the direction changes, the old result must retain its original scope. These behaviors require implementation and tests beyond a valid API schema.

The artist works in the studio’s editor. SYSTEM1 manages the project that develops and maintains the models and tools behind that interaction.

9. Improve the component that caused the failure

If the server abandons a tray, inspect the activity contract and interruption rule. If the server relaxes when the lights return, inspect the interpretation, retained concern and training examples. If a correct decision arrives too late, inspect context preparation, serving capacity and the execution schedule.

The remedy can be a tool change, a better model input, new examples or another training run. The project preserves the earlier release and compares the revised system on the same meaningful situations.

This is why models and tools develop together. The tools determine what the model can observe and do. Model failures reveal distinctions the tools or training data still need. The business can refine a capability through examples from its own work.

What works today

The core service implements defined decision tasks, grouped data preparation, real task training, candidate selection, calibration, model export and callable prediction. Its graph path compiles learned components into separate tasks and binds trained releases to their component models. Embeddable tools use validated contracts and bounded sandbox execution.

The hosted customer workflow still needs integration and qualification across the full process. Current public prototypes have separate implementation and training evidence. A prototype that uses a prebuilt model does not establish that a custom model serves it.

The reception instrument would require the scene tools, model tasks, training data, engine integration and evaluation described here. It is an example of the capability a business could commission, not an existing studio deployment.

The intended purchase is software that responds through the business’s own concepts and operations. For this studio, that means an artist can change a motive, preserve an exchange and direct the consequences while the scene continues. The model and tool development exists to make that control possible.