Who or what is acting?
Authority should bind to an explicit principal rather than being inferred from technical capability or a successful action.
PROPOSED DISCIPLINE / CATEGORY THESIS
Software Authority makes the right to change software explicit.
Software Authority is a proposed discipline for controlling who or what may change software, under what bounded conditions, with what required evidence, and through what review and recovery path.
Status matters. Software Authority is not presented here as a recognized analyst category, a ratified standard, a regulated discipline, or an established budget line. The useful question is whether the framing exposes consequential control problems that existing systems do not already solve adequately.
WHY THIS QUESTION EXISTS
Software can move faster than authority can remain clear.
Modern delivery environments distribute software change across repositories, CI/CD, identity systems, policy engines, security tools, cloud platforms, tickets, agents, operators, and recovery paths. Each system can be individually correct while the overall authority-and-evidence story becomes difficult to reconstruct.
What exact change is permitted?
Permission can be scoped to an operation, object, repository, environment, effect, stage, revision, or other bounded condition.
What makes the decision supportable?
Evidence can carry source identity, applicability, freshness, verification, completeness, conflict state, and decision context.
What happens after failure?
Recovery should preserve history and reconstruct supported context without silently reviving stale, consumed, or otherwise invalid authority.
A CORE DISTINCTION
Progress is evidence. Progress is not permission.
A task completing, an AI agent succeeding, a review passing, a pull request merging, or a deployment finishing can all be important observations. None of them should retroactively create the authority that was supposed to exist before the consequential action.
FIVE EVALUATION QUESTIONS
Test the discipline against the environment you already have.
These questions are an evaluation frame, not a claim that Causance uniquely satisfies them or that another product fails them. Existing, composed, or internally built controls should receive full credit.
T1 — Authority-state separation +
Is authority to make a consequential software change represented as explicit decision state separate from workflow progress, task completion, merge status, deployment status, or agent success?
T2 — Evidence-dependent eligibility +
Can change eligibility depend on explicit evidence or verification whose stale, missing, superseded, conflicting, malformed, or invalid state forces revalidation or blocks progression?
T3 — Reconstructable decision provenance +
Can a reviewer reconstruct what authority and evidence made a change eligible at the relevant decision point rather than infer governance from final state or logs alone?
T4 — Recovery continuity +
When failure or recovery occurs, are authority and evidence semantics preserved or explicitly re-established and revalidated rather than merely restoring code, service, or workflow state?
T5 — Substitution portability +
When a model, provider, host, tool, or environment changes, can the relevant authority and evidence state be exported, reconstructed, tested, and revalidated without silently changing its meaning?
ADJACENT CONTROL DOMAINS
Software Authority is a framing for software-change decisions, not a claim that the rest of the stack disappears.
Many existing systems already own important parts of the problem. The category thesis is useful only if it reveals a residual control gap after those systems receive full credit.
Orchestrates build, test, and deployment flow.
Software Authority asks whether the right to perform a consequential change and the evidence supporting that decision remain explicit across the flow.
Controls identity and access.
Identity and permissions are critical inputs, but a software-change decision can also depend on operation, scope, evidence, verification, review, and lifecycle state.
Evaluates rules against facts.
Policy engines can be part of the control plane. The broader framing also asks who may act, what evidence is required, what history is retained, and what happens after failure.
Governs AI systems and agents.
Software Authority focuses specifically on authority over software change, whether the actor is human, automated, or agentic.
Records controls, obligations, and evidence.
The Software Authority question is whether decision-useful authority and evidence remain connected to the exact software transition rather than reconstructed only after the fact.
Shows what systems did.
Observed effects are important evidence. They do not by themselves establish what should have been authorized before the effect occurred.
Detect and prevent important classes of risk.
Security results can be material evidence or gates. Software Authority does not replace their expertise, controls, or source truth.
Creates reusable developer and delivery platforms.
Software Authority can be evaluated as a control concern inside or across platform-engineering systems rather than as a replacement for the internal platform.
MODEL / PRODUCT / RESEARCH BOUNDARIES
Related systems remain separate.
Software Authority Model (SAM)
- SAM is a proposed, non-normative model for making authority over consequential software change explicit.
- SAM is not presented as a ratified standard or certification regime.
- A model can inform evaluation without becoming product proof or customer evidence.
Causance
- Causance is the current platform and market identity for the governed software-delivery platform.
- Claims about implemented Causance mechanics remain source- and scope-bound.
- Product implementation does not make Software Authority an established market category.
WHY THIS MATTERS IN AN AGENTIC SDLC
More autonomous execution increases the value of explicit authority.
When AI agents can plan, modify, test, review, release, or recover software with less continuous human intervention, organizations need control semantics that do not depend on a person naturally noticing every state transition.
The Agentic SDLC problem is therefore larger than agent permissions. The software condition can change across source, evidence, review, deployment, observation, and recovery. Software Authority is one proposed way to ask whether the right to make that change remains explicit and reconstructable across those boundaries.
DISCONFIRMATION
A useful category thesis has to be falsifiable.
If an organization’s installed controls already represent equivalent authority, evidence, provenance, recovery, and substitution semantics with acceptable burden, then an additional Software Authority layer may not be justified. If buyers do not recognize the problem as material, cannot identify an accountable owner, or see no incremental value beyond existing controls, the commercial category thesis weakens.
GO DEEPER