Outcomes

An outcome is a node in the graph: one concept, stated as a single, measurable thing a learner can do. Outcomes are the atoms of Open Degree. The graph connects them, courses teach them, assessments measure them, and credentials bundle them. Every outcome carries the common definition of its concept, what to learn before and after it, how to learn it, and how to prove it.

Writing an outcome

• Check for a duplicate first. Search titles and aliases. If the concept exists under another name, add your name to its aliases rather than creating a second node. One concept, one node.
• Write the statement in the first person and make it observable: “I can compute and explain the median of a dataset,” not “Understands central tendency.”
• One outcome per file. If a statement joins two different skills with “and,” split it.
• Give every outcome a level: foundation, intermediate, or advanced. Levels describe difficulty within a domain, not a grade or an age.
• Add aliases for the other names people use (“triangle congruence postulates”, “SSS, SAS, ASA”), so a search from any of them lands here.
• Add resources when you know a free or open way to learn the concept. They take the same shape as course resources; anything paid must be labeled cost: paid.
• List the evidence that would convince a stranger the outcome is met.
• Add alignments to external frameworks (state standards, industry competency models) whenever they exist. Alignments are what make an outcome portable into a school’s or an employer’s language.
• Declare prerequisites, immediate ones only. If a prerequisite does not exist yet, add it as a stub. See The Graph and Coherence Maps.
• Use ### headings in the body. The outcome’s page renders the body under its “Learn it” section, so ## would break the outline.

Stubs

If you need a node that does not exist, add it with status: stub. A stub needs only a title, a statement, and a domain; add the prerequisites, aliases, and alignments you already know. A rough statement is fine; it will be sharpened when the stub is filled. Never write a missing concept into another node’s body instead of adding a stub, because a stub can be found and linked to and a paragraph cannot.

Fields

Field	Required	Meaning
type	yes	Always outcome
title	yes	Short label, used in maps and lists
statement	yes	The measurable “I can …” statement, the concept’s one definition
description	no	Context, scope, and common misconceptions
domain	yes	Id of the domain this belongs to
level	no	foundation (default), intermediate, or advanced
prerequisites	no	Ids of outcomes to learn first
evidence	no	What demonstrates mastery
alignments	no	{ framework, code, url } entries linking to external standards
aliases	no	Other names for the concept, one per line, so search finds it
resources	no	{ title, url, kind, cost, provider } entries for learning this concept, free or open first
supersededBy	no	Id of the outcome that replaced this one. Set only when status is deprecated
status	no	stub, draft (default), proposed, adopted, deprecated. See Governance
version	no	Semantic version of this outcome, default 0.1.0
license	no	Default CC BY-SA 4.0
contributors	no	Names or handles of authors and reviewers
tags	no	Free-form tags, one per line

Example

---
type: outcome
title: Represent transformations in the plane
statement: I can represent transformations in the plane, describe them as functions that take points as inputs and give points as outputs, and compare transformations that preserve distance and angle to those that do not.
domain: "[[geometry]]"
level: foundation
prerequisites:
  - "[[define-geometric-terms]]"
evidence:
  - Given a figure and a rule, draws the image and names the transformation.
alignments:
  - framework: NYS Next Generation Mathematics Learning Standards
    code: GEO-G.CO.2
    url: https://www.nysed.gov/standards-instruction/mathematics
aliases:
  - Transformations as functions
resources:
  - title: GeoGebra Geometry
    url: https://www.geogebra.org/geometry
    kind: tool
    cost: free
    provider: GeoGebra
status: draft
version: 0.1.0
tags:
  - transformations
---

### Scope

The body of the file holds notes for teachers and learners: scope, examples, misconceptions, and links.

References can be written as a plain id (define-geometric-terms) or as an Obsidian wikilink ("[[define-geometric-terms]]"). Both resolve to the file src/content/outcomes/define-geometric-terms.md.

A stub

---
type: outcome
title: Prove triangles congruent with SSS, SAS, and ASA
statement: I can explain how the SSS, SAS, and ASA criteria for triangle congruence follow from the definition of congruence in terms of rigid motions, and use them to prove two triangles congruent.
domain: "[[geometry]]"
prerequisites:
  - "[[prove-congruence-with-rigid-motions]]"
status: stub
---

That is the whole file. Someone reached for this concept and it did not exist, so now it does. It appears in the graph, it can be a prerequisite, and it is waiting for evidence, resources, and a body.