한국어 | English

Governance and Evidence

"Work Was Performed" Is Not the Same as "The Task Is Complete"

An LLM saying "implemented," "tests passed," or "no issues found" is not sufficient evidence of completion.

AGS is designed to keep the completion claim separate from the evidence supporting it.

Task Contract

At the beginning of a task, the system can establish:

• goal,
• scope,
• completion criteria,
• risk,
• authority,
• and validation requirements.

Later decisions are evaluated against that frame.

The contract provides concrete answers to questions such as:

• What is supposed to change?
• What is allowed to change?
• Which checks are required?
• Who has authority to perform the action?
• What must be true before the task can be considered complete?

Change Scope

As work progresses, the current changes can be compared against the original baseline.

Unexpected files, scope expansion, or altered assumptions become explicit review items instead of silently entering the final result.

Mutation Risk Preflight

For higher-impact changes such as deployment, permission changes, destructive actions, or data mutation, a preflight can verify:

• exact target,
• user approval,
• expected impact,
• rollback conditions,
• and required independent review.

Evidence

Completion should be tied to current artifacts whenever possible.

A useful chain is:

Requirement
    ↓
Changed artifact
    ↓
Executed validation
    ↓
Validation result
    ↓
Open findings
    ↓
Completion decision

Evidence can include file references, digests, test outputs, structured stage results, and other traceable artifacts.

Independent Audit

For high-risk work, implementation and audit should not rely on the same role by default.

An independent auditor can examine:

• requirement coverage,
• scope drift,
• evidence freshness,
• plausible failure modes,
• unresolved findings,
• and overreliance on self-validation by the implementer.

If the audited artifact changes materially, the affected parts should be reviewed again rather than automatically inheriting an earlier PASS.

Workflow Gates

Within an integrated workflow, the runtime can enforce structural conditions such as:

• planned execution order,
• revision consistency,
• stage output schemas,
• required artifacts,
• required stages,
• unresolved blockers,
• audit requirements,
• and completion conditions.

A final completion receipt is only emitted when the required gates are satisfied.

Execution Observation

At strict MCP boundaries, caller-provided executionContext is not treated as trusted observation.

Supported host adapters bind observed execution properties to the relevant call, and the runtime checks freshness, identity binding, replay resistance, and stage-level execution requirements.

This does not mean that a stronger model automatically produces a correct result.

The purpose is to prevent an execution below the required class from silently passing a stage that was declared to need stronger execution.

Failure and Recovery

When completion fails, AGS favors diagnosis over blind repetition.

A typical recovery flow is:

Observed facts
     ↓
Cause hypotheses
     ↓
Discriminating test
     ↓
Confirmed cause
     ↓
Recovery strategy
     ↓
New handoff / new workflow

The failed run remains part of the history. Recovery proceeds through a new handoff and a new execution rather than rewriting the prior record.

Trust Boundary

AGS is not an OS-level security boundary against malicious processes running under the same user account.

It also does not automatically authenticate the semantic truth of every user-supplied evidence item.

Its role is to provide stronger operational governance over AI work.

Environments with stronger adversarial requirements may need additional systems such as:

• authenticated actor identity,
• content-addressed evidence stores,
• protected approval surfaces,
• or OS-level isolation.