SALC
SOFTWARE AUTONOMOUS LIFE CYCLE
The AI operating system for autonomous software delivery.
From requirements to release, SALC keeps software intelligence connected, traceable and human-governed.
Software delivery is becoming agentic.
SALC is the control plane that keeps it governed.
AI can generate software faster than ever.
Software delivery is still fragmented.
Existing AI tools optimise isolated tasks — meeting summaries, coding, test generation, DevOps assistance. Each one starts from a blank context, produces output nobody can trace back to a requirement, and leaves no connective tissue behind.
in a PRD nobody re-reads
in a repository
in a test management tool
in a pipeline log
in a dashboard
A requirement changes. Nobody can answer which tests are now wrong, which generated code is now stale, or which release is now risky — without a person remembering.
Five tools.
Five contexts.
No connective tissue.
Each tool holds a fragment of the truth. The handoffs between them are where context is lost, and where AI-generated output becomes unverifiable.
Six moves, one governed pass
The sequence is the same whether the trigger is a document upload or a changed ticket — which is what makes the output comparable from one run to the next.
- 01Understand
Documents become Source Artifacts and an immutable, cited knowledge snapshot.
- 02Generate
Risk-weighted strategy, scenarios and test cases in a vendor-neutral model.
- 03Verify
Five deterministic rules accept or reject the output. No model involved.
- 04Approve
A person freezes a specific version. Later edits cannot change what was approved.
- 05Deliver
Publish to test management; generate automation on an isolated branch.
- 06Learn
A requirement change traces forward through everything it invalidates.
A control plane, not another tool beside the tools
Read “control plane” literally: SALC decides what should be tested, why, and whether the output is acceptable — then hands executable artifacts to the systems that already exist.
Components communicate only through versioned contracts
No component reads another's tables. Typed inputs and outputs, events, artifact references, job handles and approval tokens.
All AI access goes through one gateway
Routing, prompts, budgets, caching, retries and audit in a single boundary. A direct provider call anywhere else is critical drift.
Two vendor-neutral data models carry the weight
The Source Artifact preserves provenance; the Test Specification Model is what every publishing adapter consumes — never raw AI output.
Additive by construction
A new connector, generator or publishing adapter registers against contracts that are already frozen, without reopening the orchestrator.
AI generates.
Deterministic rules verify.
An LLM that generates test cases and an LLM that grades them is one system marking its own homework. A deterministic rule engine that rejects generated output for measurable, stated reasons is a different product.
Requirement traceability
Test cases linked to a requirement: 147 / 147
Expected results
Test cases with a stated, observable outcome: 147 / 147
Boundary coverage
Requirements stating a limit: 10
Negative coverage
Requirements requiring negative coverage: 29
Test-data completeness
Test cases requiring data: 147
On the demo project, three of these pass and two fail — on real gaps the engine found in AI-generated output. That is the point of the screen, not a flaw in it.
See the findings →One chain, versioned end to end
A generated test traces back to the sentence that justifies it. A changed requirement traces forward to everything it invalidates. Both directions matter; only one of them is usually built.
Lineage coverage is 94% rather than 100% because two requirements sit behind an open contradiction. SALC refuses to count a chain as complete while its source disagrees with itself.
Change one number. Watch it propagate.
This is a traversal of the lineage graph, not a search for a string. SALC distinguishes an assertion that is now wrong from an artifact that merely needs a second look.
SALC doesn't just generate artifacts. It understands what changed.
Run it yourself →A narrow first release inside a much larger vision
The full lifecycle is the vision, not the first release. Being explicit about that distinction is part of the argument, not a caveat attached to it.
Quality engineering control plane
An autonomous testing control plane that converts changing product knowledge into traceable, reviewable and executable test coverage, with human-governed trust.
- Source ingestion and product knowledge
- Test intelligence and the test specification model
- Quality Principles Engine
- Human approvals and export
Publishing and automation
Additive capabilities that register against contracts frozen in the first stage, without reopening the orchestrator, the knowledge model or the quality engine.
- Azure DevOps test plan publishing
- Playwright TypeScript generation
- GitHub pull requests on isolated branches
- Design-to-implementation conformance
Autonomous delivery operating system
The broader lifecycle: business discussion, requirement discovery, product planning, architecture, development, deployment, monitoring and continuous improvement.
- Secure execution runners
- Results and defect intelligence
- Release-readiness intelligence
- Enterprise connectors and workflow canvas
SALC is being built as the control plane for AI-driven software delivery. It is a prototype under active development, not a finished commercial product — and the first release focuses on quality engineering and governed automation.
The demo runs the real thing.
Run the workflow, watch the quality engine reject generated output for stated reasons, approve a frozen snapshot, generate automation, then change one requirement and trace the damage.