Skip to content
QL
SALC principles

Seven invariants that hold across every stage

These are the substance of the claim that SALC is not a wrapper. They cost real engineering time, and each one is visible somewhere in this demonstrator.

01

Context survives the workflow.

The value is not in any single generation step. It is in the connected, versioned context that persists between them — which is what makes a requirement change traceable forward and a generated test traceable back.

See it in the product
02

AI output must be traceable.

Every AI output cites the source artifact it came from. Citations are stored as relationships to an artifact version and a locator, never as text copied into the output.

See it in the product
03

Contradictions are surfaced, not hidden.

A system that quietly picks an interpretation when the specification conflicts with itself produces output that looks authoritative and cannot be falsified. The contradiction is the finding.

See it in the product
04

Quality is independently validated.

The Quality Principles Engine is deterministic and separate from generation. If a rule needed a model to decide, it would not be a quality principle — it would be more generation.

See it in the product
05

Humans remain accountable.

Approval freezes an immutable version. Later edits create successors; they cannot retroactively change what was approved. An approval record that can be altered is not an approval record.

See it in the product
06

Generated code never goes directly to main.

Automation lands on an isolated branch and opens a pull request for an engineer. Generated code is a proposal, and nothing here claims it is production-safe.

See it in the product
07

Every AI decision is auditable.

User, component, version, model, prompt version, cost and duration — recorded for every call, because all model access passes through one gateway. Cost is treated as a correctness property.

See it in the product
How SALC thinks

One pass, seven moves

The sequence is the same whether the trigger is a document upload or a changed ticket.

  1. SOURCE

    Documents arrive as untrusted input and are normalised

  2. CONTEXT

    An immutable, cited knowledge snapshot is built

  3. REASON

    Risk and coverage strategy derived from that snapshot

  4. GENERATE

    Scenarios, cases and automation produced by models

  5. VERIFY

    Deterministic rules accept or reject the output

  6. APPROVE

    A person freezes a specific version

  7. ACT

    Publish, generate automation, raise a pull request

AI
Generation

Fast, cheap, and unaccountable on its own

SALC
Context + verification + governance

The connective tissue that makes the output usable

Human
Accountability

Approves, reviews, and owns the decision

KNOWLEDGEGENERATEVERIFYAPPROVEDELIVERLEARNSALCCONTINUOUS LOOP
Scope, stated plainly

What is built, what is designed, what is vision

The full lifecycle is the long-term vision. The first release is deliberately narrower.

V1Autonomous testing control plane

Converts changing product knowledge into traceable, reviewable and executable test coverage, with human-governed trust. Design-to-implementation conformance sits inside this as a component, not as a separate product.

Ring BPublishing and automation generation

Azure DevOps publishing, Playwright TypeScript generation and GitHub pull requests. Additive: each one registers against contracts that are already frozen.

FutureBroader lifecycle orchestration

Execution runners, defect intelligence, release readiness and the wider lifecycle — business discussion through to monitoring and continuous improvement.

“Autonomous” is aspirational and staged. Every generation step in the first release terminates at a human approval gate. Autonomy means the chain runs without hand-carrying artifacts between tools — not that a person is absent.

Interactive product demonstrator. This experience illustrates the designed SALC workflow using simulated project data. Production integrations and capabilities are being developed.