Private runner • Built on Lex 2.0.0

LexRunner: Deterministic Merge Pyramid

LexRunner is a proprietary merge-weave runner built on Lex 2.0.0 contracts. It reads a single frozen merge plan, runs uniform gates locally and in CI, and applies dependency-ordered merges so the same inputs always produce the same sequence. Recent governance hardening (private) improves capability tiers and admin authority controls to make orchestration safer and more auditable.

Status: Active development • Private repo (request early access) • Consumes stable Lex contract surfaces

Built on Lex Contracts

LexRunner is a consumer of Lex's stable contract surfaces, not a hidden author of them. The boundary is clear:

  • Lex (OSS) owns Frames (episodic memory), lexmap.policy.json (architecture boundaries), and lex.yaml (workflow contracts).
  • LexRunner (private) consumes those contracts and implements a deterministic merge pyramid. Its internal plan formats stay private.

This separation means you can adopt Lex for policy-aware recall today without ever touching LexRunner. If you do integrate LexRunner, it uses contracts that are already part of the OSS story.

Lex 1.0.0 lex.yaml Contracts

Core Goals & Invariants

Single Frozen Input

Integration runner consumes only a single, versioned merge plan document. No implicit state; no issue scraping at runtime.

Deterministic Merge Pyramid

Topological order from leaves → root with stable sorting. Same plan → same ordered merge decisions.

Uniform Gates

Identical gate semantics locally & in CI (linting, type/contract checks, tests, policy). A small, fixed status model (pass/fail/blocked/…) drives eligibility.

Separation of Concerns

Lex owns memory, policy, and contracts; LexRunner owns orchestration. That separation keeps reasoning explainable and behavior predictable.

Auditability & Receipts

Gate results are structured artifacts; merge decisions trace back to explicit plan + policy fields. Lex Frames provide the memory substrate.

Integration Contract (high-level)

At integration time, the runner consumes a single, versioned merge plan produced by your orchestrator. The public site describes concepts only; detailed structures and examples are private.

Plan as Single Input

One frozen merge plan drives ordering, gate execution, and eligibility. No implicit sources are read during integration.

Declared Dependencies

Dependencies are explicit in the plan; the runner does not infer edges. Deterministic ordering respects those declarations.

Gates & Policy

Named checks are evaluated per node with policy indicating which are required and how retries/concurrency are handled.

Versioned Contract

The plan format is versioned for safety. Specific field names, file names, and validation rules are intentionally not published here.

Determinism

Same inputs yield the same outcomes, including stable ordering. This enables reproducible local and CI runs.

Note on Examples

To protect IP, we intentionally omit concrete wire formats and field names on this page. If you need to integrate, request access and we’ll share the private reference.

Gate Execution & Status Model

Gates run uniformly in local and CI environments under policy control (required vs optional, retries, concurrency). Tooling specifics and exit semantics are kept private; what follows is concept-level only.

Static Analysis

Style and quality checks to maintain consistency and catch common issues early.

Type/Contract Validation

Validates interfaces and contracts to prevent integration mismatches.

Tests

Executes project tests. Policy determines which results are required for eligibility.

Status Semantics

Gates report a small, fixed set of standardized states. Detailed mappings and artifacts are part of the private reference.

Merge Pyramid Flow

Fan-out implementation PRs, then weave back deterministically from the base: validate plan, execute gates, merge eligible leaves upward.

🎯 Smart Dependency Resolution

Automatically determines the correct order for merging PRs based on declared dependencies. Prevents merge conflicts and ensures changes integrate cleanly without manual intervention.

⚡ Parallel Execution

Independent work streams merge concurrently, maximizing throughput. The system identifies which changes can safely proceed in parallel while respecting dependencies.

🛡️ Conflict Prevention

Intelligent ordering minimizes merge conflicts before they occur. By understanding the dependency graph, the platform sequences merges to avoid integration issues.

📊 Predictable Results

Same inputs always produce the same merge sequence. Reproducible builds and deterministic behavior ensure consistency across local development and CI environments.

Ready to adopt the merge pyramid?

Start with Lex 2.0.0 for policy-aware recall, define your workflows in lex.yaml, and produce a single, versioned merge plan for the runner. LexRunner is private for now — request access or track the roadmap. We continue to improve governance, turn cost tracking, and capability tiers in private workflows.

Request Access Lex 2.0.0 lex.yaml Roadmap