What you need to know
- Trajectory combines model training, evaluation and deployment in one announced platform.
- Its grading preview learns a procedure for producing task-specific graders.
- A changed model and a changed definition of success need distinguishable records.
Expertise enters the training stack
Trajectory announced its post-training platform on November 2 alongside a $45 million Series A led by Sequoia. The company describes a product that accepts tasks and a way to score them, then connects training, evaluation and deployment. Continual Grading is one of its research previews.
Our reading is that the product gives a familiar business asset a new technical role. An experienced colleague can recognize a good result, but a training process needs a repeatable way to turn that judgment into a signal. The interface between those two forms of expertise becomes part of the software being built.
The grader has a program of its own
Trajectory’s technical account describes a metagrader: a procedure learned from a small set of expert-graded tasks that constructs a grader for a new task. The learned artifact is prompts and code working with a fixed judge model, rather than another set of reward-model weights. Its rubric approach makes individual criteria visible so an expert can inspect or correct them.
That creates two things to examine: the system doing the work and the procedure deciding how that work is scored. Our interpretation is that a clear answer to the second question helps explain the direction in which training pushes the first.
Consider a hypothetical support task with two plausible replies. One explains the issue fluently; the other also routes a request to the required team. If routing is part of a successful outcome, a criterion should make it visible. This example illustrates a grading choice, not a reported Trajectory customer result.
Choosing a grader and measuring its result are different steps
The company’s research distinguishes the roles of examples used to construct a metagrader, select it, train the task-performing model and evaluate the outcome. It also identifies overfitting to the small selection set as an open problem.
In our view, this makes the scoring procedure something to track through versions. A team comparing two training runs needs to know whether the model changed, the grading criteria changed or both. Otherwise, a higher score could be hard to interpret.
The support example makes the distinction concrete. Adding a routing requirement would change what counts as success. That might be the right decision, but the new score would answer a different question from the earlier one. Keeping the criterion change visible would preserve the meaning of the comparison.
The training artifact meets release control
Trajectory’s product page says users define which data can enter training and that model updates pass through their evaluation suite and approval workflow before production. Those are company descriptions of the controls, rather than findings from our own platform test.
The broader shift is that domain judgment becomes a maintained part of the training stack. A useful operating record would connect the task examples, grading procedure, resulting model and release decision. That is our proposed way to assess the product’s role as organizations use it; it is not a claim about achieved accuracy, cost savings or universal access to the research previews.
