GTDataworks-Labyrinth

Runtime for the GTDataworks pipeline.

External tasks / scenarios / sessions
                |
                v
        GTDataworks-Labyrinth
              RUNTIME
                |
         sealed run evidence
                v
        GTDataworks-EvalFoundry
               EVALS
                |
         evaluated lineage
                v
        GTDataworks-Refinery
       PRODUCTIZATION / SALES

Purpose

Labyrinth is the authoritative execution and evidence-capture system for consequential agent work.

It answers one primary question:

What actually happened?

Labyrinth runs admitted work, witnesses the resulting actions and state, preserves the evidence, and emits sealed run artifacts that downstream systems can evaluate and refine.

Labyrinth owns

• agent/model execution
• coding sessions and full scenarios
• tools and skills
• workspace and environment execution
• provider/model exchange capture
• shell, process, action, result, file, and artifact evidence
• runtime authority and safety boundaries
• checkpoints and snapshot primitives
• exact child-execution primitives requested by EvalFoundry
• lineage primitives
• cleanup verification
• run sealing
• preserved run archives, including sealed ZIP bundles

Labyrinth does not own

• seed or corpus generation
• scenario ideation or exploratory domain discovery
• grading or evaluation policy
• Oracle judgment
• deciding whether a run should be replayed
• correction/intervention generation
• preference or quality labels
• dataset inclusion decisions
• sale-readiness or publication

Seeds, scenarios, coding tasks, and other workloads are authored outside GTDataworks and enter Labyrinth as admitted inputs.

Runtime split

Labyrinth is intended to support two execution products without collapsing their authority models into one permissive runtime.

General Runtime

Built first for normal consequential agent work:

• coding and debugging sessions
• full tools and skills
• normal admitted networking
• admitted credentials
• real repositories and workspaces
• stateful, multi-turn execution

Contained Range Runtime

Derived after the shared runtime/evidence contracts are stable. It is a separately restrained runtime for cyber ranges and other closed local worlds.

Its goal is real execution with real consequences inside a controlled environment, while structurally removing dangerous external reach:

• real shell and network tooling
• real internal HTTP/DNS/TCP/UDP services
• real files, processes, credentials, and state inside the range
• no public Internet route
• no host/LAN reachability
• no ambient provider/cloud credentials
• no uncontrolled host mounts
• containment attestation and evidence

The model does not need to be told that the environment is contained; the environment itself enforces the boundary.

Primary evidence rule

A sealed Labyrinth run is immutable primary evidence.

A typical preserved root artifact is:

sealed-run.zip

Downstream systems may read, extract, segment, evaluate, normalize, redact, combine, and otherwise derive from a sealed run. They must not rewrite the sealed source and continue treating the modified bytes as the original run.

Provenance is preserved through lineage, not by forbidding downstream transformation.

Interface to EvalFoundry

EvalFoundry owns replay as an evaluation workflow. Labyrinth owns only the mechanical runtime primitive required to execute a requested child.

sealed parent
    |
    v
EvalFoundry evaluates / selects replay
    |
    v
frozen replay request
    |
    v
Labyrinth restores checkpoint and executes child
    |
    v
sealed child
    |
    v
EvalFoundry compares / grades / verifies

Labyrinth must be able to execute and seal runs independently of EvalFoundry or Refinery.

Pipeline boundary

Labyrinth = Runtime.

It executes, observes, captures, checkpoints, seals, and preserves.

It does not decide whether the evidence is good, preferred, commercially useful, or sale-ready.