Skip to content
Open DegreeOpen Degree

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

Section titled “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

Section titled “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

Section titled “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
volatility no How settled the claim is: stable, evolving, frontier. Not how hard it is; that is level
evidenceClass no What the strongest evidence behind it is: peer_reviewed, preprint, vendor_docs, single_source, mixed
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

Resource fields

Section titled “Resource fields”

A resource needs only title, url and kind; cost defaults to free and must be honest. The rest is optional, and exists so a platform can rank, fit and lawfully surface it without guessing:

Field What it is
subKind A narrower form within kind: course, lesson_plan, syllabus, worksheet, paper, preprint, docs, changelog, podcast, talk, repo. It has to fit its kind: a talk is a video, a paper is a reading
audience Who it suits: rating (all, teen, older_teen, adult, unrated), descriptors, and the basis for the rating. No block at all means unrated; only human review raises a rating
publishedAt When the resource itself was published
externalIds doi, arxiv, openalex, isbn, youtube, vimeo, … so two products mean the same thing
evidenceSignals citationCount, venue, peerReviewed, retracted and friends. Advisory, never a ranking
transcript Whether the words can be read, and under whose terms
platformId The platform it lives on
provider, modality, durationSeconds, difficulty, language, hasCaptions, license, attributionText, sourceUrl, embedPolicy, coverage, lastVerifiedAt As before

Write a timestamp in quotes ("2026-09-23T00:00:00Z"), so it stays a string in YAML.

Example

Section titled “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

Section titled “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.