Skip to content

Latest commit

 

History

History
214 lines (145 loc) · 5.44 KB

File metadata and controls

214 lines (145 loc) · 5.44 KB
title AWO Scope Definition
filetype documentation
type specification
version 2.0.0
doi 10.5281/zenodo.18201829
status Active
created 2026-01-07
updated 2026-01-09
author
name email orcid
Shawn C. Wright
swright@waveframelabs.org
maintainer
name url
Waveframe Labs
license Apache-2.0
copyright
holder year
Waveframe Labs
2026
ai_assisted partial
ai_assistance_details AI-assisted drafting under human governance; aligned with AWO v2 Design Envelope and Minimal Phase Topology.
dependencies
../DESIGN_ENVELOPE_MINIMAL.md
../PHASE_TOPOLOGY.md
anchors
AWO-SCOPE-v2.0.0

Aurora Workflow Orchestration — Scope Definition

1. Purpose

This document defines the formal scope boundary of
Aurora Workflow Orchestration (AWO) v2.0.0.

It specifies what AWO defines, what it explicitly does not define,
and how it interfaces with upstream (doctrine / governance) and downstream
(enforcement / tooling) layers.

This document is normative with respect to AWO’s methodological domain only.
It does not confer epistemic, institutional, or enforcement authority.


2. Scope Summary

AWO defines and controls:

  • the structural ordering of governed workflows,
  • required workflow phases and permitted transitions,
  • required artifact classes per phase,
  • structural completeness requirements for artifacts,
  • role participation constraints per phase,
  • linkage and reference requirements enabling traceability.

AWO does not define, judge, or adjudicate:

  • epistemic legitimacy or truth,
  • semantic correctness of claims,
  • enforcement or validation outcomes,
  • runtime execution behavior,
  • publication or dissemination decisions,
  • scientific validity or merit of results.

AWO defines how work is recorded and structured,
not what conclusions are correct or accepted.


3. Positive Scope (What AWO Controls)

When a workflow is declared AWO-governed, AWO has authority over method structure only, including:

Domain AWO Authority
Workflow Structure Required phases and allowed transitions
Artifact Taxonomy Required artifact types and relationships
Structural Requirements Mandatory fields, references, and declarations
Role Participation Which roles may act in which phases
Traceability Enablement Structural links enabling reconstruction

If AWO requires an artifact or declaration and it is missing,
the workflow is structurally non-compliant.

AWO does not evaluate artifact content, conclusions, or correctness.


4. Explicit Out-of-Scope Domains

AWO MUST NOT:

  • perform enforcement or verification,
  • adjudicate scientific correctness or legitimacy,
  • define epistemic doctrine or disclosure policy,
  • select tools, models, or implementation methods,
  • dictate repository layout or storage mechanisms,
  • govern post-release activity or dissemination.

These responsibilities belong to ARI, NTD, NTS, CRI-CORE, and tooling layers.

AWO is method only, never execution, judgment, or authority.


5. Workflow Boundary Model

A workflow enters AWO scope when:

  1. An intentional unit of work is declared, and
  2. A compliant Initiation Artifact is created.

A workflow exits AWO scope when:

  • A Release Artifact is produced that freezes the workflow iteration.

Any approval, attestation, audit, or enforcement activity occurs
outside AWO scope, even if it references AWO artifacts.


6. Phase Boundary Alignment

AWO governs exactly the following phases:

Initiation → Specification → Execution → Review → Release

AWO defines:

  • the order of these phases,
  • the artifacts required at each phase,
  • the roles permitted to act in each phase.

AWO defines no outcomes beyond Release.


7. Upstream / Downstream Interaction

Upstream (AWO must obey)

Layer Authority
ARI Institutional authority and governance
NTS AI disclosure and cognitive provenance
NTD Epistemic rationale
Role Separation Charter Conflict and independence rules

Downstream (AWO enables)

Layer Uses AWO Artifacts For
CRI-CORE Enforcement and validation
Forge / Stamp Publication and freezing
Case Studies Executed research workflows
External Tools Validation, linting, inspection

AWO is a hinge layer: constrained upstream, operationalized downstream.


8. Misinterpretation Safeguards

AWO compliance does not imply:

  • research quality,
  • scientific correctness,
  • publication worthiness,
  • legitimacy of conclusions,
  • credibility of contributors.

AWO ensures only that:

a workflow can be reconstructed, inspected, and challenged
without trust in the author.


9. Change Control

Any change that modifies:

  • required phases,
  • required artifacts,
  • role permissions,
  • structural requirements,

is a breaking methodological change requiring a major version increment.

Clarifications that do not change meaning may be patch-level updates.


10. Compliance Requirement

This document is valid only if its metadata complies with
ARI Metadata Policy v2.0.0.

Non-compliance voids AWO scope authority.


© 2026 Waveframe Labs — Governed under the Aurora Research Initiative (ARI)