Skip to main content
News · Oct 27, 2026

Artifact GRID is now running in our tests

The next layer of Obsigen GRID: models don't pass content to one another — they build a shared, verifiable state of knowledge about the task. Here's one test run, step by step.

Obsigen GRID already selects the right models for every task based on measurements, and in Titan mode it verifies the result before it reaches you. The next layer — Artifact GRID — is now running in our internal tests.

In tests

Artifact GRID in three layers. Top: the contract and six modules of a 3D platform game, connected by APIs that are checked for compatibility. Middle: the blackboard, a shared state of knowledge about the task, where every artifact, hypothesis and test result lands as a reference. Bottom: memory in the customer's tenant. Around the blackboard runs the communication protocol: models α to δ and the test runner exchange references, not content. In this run, three earlier artifacts are recalled from memory, all six API checks pass, a browser test falsifies one player conclusion and the two conclusions built on it are retracted; after a fix and a re-run they are verified again, and 24 conclusions with their lineage are stored back in memory.

Visualization of an internal test run · sample task: a 3D platform game · codes are illustrative

What happens in a run

In Artifact GRID, models don't pass content to one another. Instead, they build a shared, verifiable state of knowledge about the task: hypotheses, artifacts and test results are added to it through references. Every conclusion has a provenance, and verification decides what is true. The scene above shows the four parts that make it work:

  • Modules, a contract and APIs. The task brief is linked to a contract — one shared description that every part of the work is built against. The contract itself is checked, and so are the APIs between the modules: parts that don't fit each other are caught before anything is run.
  • The blackboard. The shared state of knowledge about the task. Every artifact, hypothesis and test result lands there as a reference, together with what it rests on — so each conclusion can be traced back to where it came from.
  • The protocol. Models and tests communicate through a protocol built on references: they point to a file, a code fragment or a test result instead of retelling it. Nothing gets lost in a summary of a summary.
  • Memory. Earlier artifacts can be recalled from memory, and verified conclusions are stored back there, with their lineage — in your tenant.

One test run, step by step

The task in this internal test run: a small platform game with 3D elements that runs in the browser. Here is the same run, flattened:

The same run, flattened: sources → contract → modules → tests → conclusions

One test run: the task brief is linked to a contract, and the contract is checked. Six modules of a 3D platform game — input, physics, level, player, world and HUD — are built against it. Each module goes through tests and a run. The player test fails first; the finding goes back to the module with its evidence, and the re-run passes. Every passing result becomes a conclusion with its provenance: 24 conclusions in total.

Visualization of an internal test run · sample task: a 3D platform game · codes are illustrative

  1. A contract first. The task brief is linked to a contract, and the contract is checked.
  2. Six modules, compatible APIs. The game is split into six modules: input, physics, level, player, world and HUD. All six are built against the same contract, and the APIs between them are checked for compatibility.
  3. Tests and runs. Each module goes through tests, and the game is run in a browser. In this run, the browser test covered three key mechanics: stomping on an enemy, losing a life after a fall and reaching the flag.
  4. A failed test is a finding, not a conclusion. One check failed: stomping on the enemy didn't defeat it. A conclusion refuted by a test goes dark together with the conclusions built on it, and the finding goes back to the module for a fix — with the evidence from the test.
  5. Conclusions with a provenance. What passes verification becomes a conclusion in the shared state, and every conclusion points back to where it came from.

Why it matters

For a company, the hard question about AI is rarely "can it write this?" — it's "how do we know it's right?" Agreement between models is not proof (see multi-agent systems in our AI Compass). In Artifact GRID, tests and evidence decide.

What's next

Artifact GRID is in internal tests. Details will be published on obsigen.com on launch day. Until then, see how Obsigen AI works today.

Have a similar problem in front of you?

30 minutes. We tell you the smallest engagement that gets you a defensible answer.

Talk to us