[3.1] Profile objective & scope

[ozzyathome]

Aspect

Section: 3.1 Profile objective & scope
Orientation relevance: both

Objective

Decide how a profile states the decision or process it exists to support, declares its
orientation, and bounds what it covers — so that attribute selection has an anchor and
conformance can be judged.

Background & links

Scoping document §3.1 (rationale and decisions) and §2.1–2.2 (why a profile needs a stated
objective and a floor/ceiling). The orientation distinction is set out in §2.5. This aspect
produces the "preamble" that every other aspect's output hangs from.

Options under consideration

• Mandatory structured preamble — every profile opens with required fields: objective,
  intended consumers, supported decision(s), orientation, and an explicit in-scope / out-of-scope
  boundary. (Trade-off: more upfront rigour; slightly heavier to author.)
• Light objective statement + minimal metadata — free-text objective plus a small fixed
  field set. (Trade-off: lower barrier; weaker comparability across profiles.)
• Scope boundary expression — by component type, asset domain, interface, or lifecycle
  stage, or a declared combination of these.

Open questions

• A required template for stating a profile's objective, intended consumers, and supported decision(s).
• Whether and how a profile declares its orientation (inventory / migration), and the consequences of that declaration.
• How a profile's scope is bounded, and how that boundary is expressed.

Dependencies

Feeds the obligation rules (3.4 #6) and roadmap scope (3.10 #10). Largely independent
to start; no hard upstream blocker.

Decision

Not yet decided.

Impact on the specification

Spec section "Defining a profile: objective, scope, and orientation."