Documentation
The fields, hierarchy, tier, and lifecycle states for every artifact type. This catalogue is generated from the same definitions Helen’s Foundry uses to validate artifacts.
Helen’s Foundry grades each artifact against the questions below. Every type except ticket uses these shared criteria. Each type section adds its own criteria. Tickets use their own criteria set instead of the shared criteria.
Can the artifact's material commitments, including any acceptance clauses, hold simultaneously under their stated conditions?
Passes when: Material commitments are compatible under the same conditions.
Does each material empirical claim, such as a measured result, prevalence, or proven effect, cite its evidence or say that it is unverified?
Passes when: Each material empirical claim cites its evidence or is labeled as unverified. Aspirations, plans, definitions, decisions, expectations, and the author's own account of their situation and resources are not empirical claims.
Do the title and content agree on the artifact's intent?
Passes when: Title and content describe the same intent.
Can the intended reader identify the actors, actions, and claims without guessing or repeated rereading?
Passes when: Actors, actions, claims, and necessary terms are concrete and clear to the intended reader.
Does each passage contribute information, reasoning, or necessary context?
Passes when: Passages contribute without repetition, filler, or empty formulaic framing.
Does the organization make the artifact's purpose and reasoning easy to find?
Passes when: Organization supports the intended reader and artifact purpose.
Does each approval, sign-off, authorization, or decision the text relies on name who gave it or where it is recorded?
Passes when: Every approval or decision the text relies on names who gave it or links to where it is recorded, or the text relies on none.
When an artifact has a specification with acceptance clauses, these criteria also apply.
Does each acceptance clause state one unambiguous obligation with a clear subject and conditions?
Passes when: Every clause has a clear subject, obligation, and applicable conditions.
Can each clause be decided with an observable pass/fail result: for software, from a pull request's diff and its tests or a live performance run; for other work, from a stated record or observation? Judge the supplied clauses only, not completion checks the description lists. Rate the least verifiable clause.
Passes when: Each clause states an observable pass condition: a property a diff and tests or a live performance run can decide, or, for non-software work, a stated record or observation. A clause about code structure, repository configuration, registration, error handling, or runtime behavior that a test or code review can check is verifiable.
Do the acceptance clauses cover the artifact's material promised outcomes, relevant failure behavior, and scope boundaries?
Passes when: Clauses cover the material outcomes, relevant failure cases, and scope boundaries.
Is every acceptance clause needed for the stated intent?
Passes when: Each clause contributes to the intent; constraints are justified by the stated intent.
Is each acceptance clause consistent with the artifact's current description, without contradicting or distorting it? Clauses stand on their own: a clause may state an obligation the description does not mention. Concrete detail that carries out a described outcome, and a restatement of the description's own completion check, are faithful. A description of current or broken behavior states the problem, not an obligation, so a clause requiring the fix does not contradict it. Rate the least faithful clause.
Passes when: No clause contradicts or distorts the current description; a clause that restates a described obligation keeps its conditions. A clause stating an obligation the description does not mention is faithful.
Does every acceptance clause state a checkable obligation about the work, rather than a delivery step or a broken sentence?
Passes when: Every clause is a complete obligation about the behavior or properties of the work.
missionDefine purpose, customers, and identity
No type-specific fields.
In addition to the shared criteria:
Can a reader identify whom the organization exists to serve?
Passes when: Beneficiaries are identifiable by a meaningful scope.
Does the mission state the enduring benefit or change the organization exists to create?
Passes when: An enduring benefit or change is explicit.
Does the mission explain the organization's distinctive contribution beyond generic superiority claims?
Passes when: A concrete contribution distinguishes the organization's approach.
Does the purpose provide a meaningful basis for deciding which opportunities fall outside the mission?
Passes when: Purpose gives a usable boundary for excluding opportunities.
Do the stated principles guide choices when desirable outcomes conflict?
Passes when: Principles supply priorities or decision rules for tradeoffs.
visionThe ideal future state we are building toward
No type-specific fields.
In addition to the shared criteria:
Does the vision describe a future condition rather than a list of activities?
Passes when: A recognizable future condition is described.
Is the intended change for beneficiaries understandable?
Passes when: The change in beneficiaries' experience or situation is explicit.
Are there observable indications by which stakeholders could recognize progress toward this future?
Passes when: The future state or stated signals include concrete qualitative or quantitative conditions that distinguish progress.
Does the vision provide enough direction to distinguish relevant strategic choices from unrelated ones?
Passes when: The future state discriminates relevant choices.
strategyA time-bound 12–18 month plan connecting vision to execution
No type-specific fields.
In addition to the shared criteria:
Does the strategy choose the customers, problems, or markets where effort will concentrate?
Passes when: A bounded arena of concentration is explicit.
Does the strategy explain how its chosen actions will produce the intended outcomes?
Passes when: A plausible causal mechanism connects actions and outcomes.
Does the strategy name meaningful alternatives or activities that will receive less attention?
Passes when: Explicit tradeoffs distinguish chosen and forgone alternatives.
Is the proposed approach plausible given the stated capabilities and resource constraints?
Passes when: Required capabilities and resources are compatible with the stated constraints.
Does the sequence of actions respect their material dependencies?
Passes when: Ordering respects dependencies or explicitly establishes that actions are independent.
Does the strategy name evidence that would cause it to be reconsidered?
Passes when: Observable evidence or thresholds trigger reconsideration.
goalA measurable outcome that advances the strategy
metric_type text EnrichingIs this a leading indicator (predictive) or lagging indicator (outcome)? e.g. leading: weekly active usage; lagging: quarterly revenue
time_period text EnrichingWhat is the time horizon for this goal? Is it part of a quarterly cycle or tied to a specific milestone? (e.g. Q2 2026, H1 2026)
target_date date CoreWhen should this goal be achieved?
target_value number EnrichingThe numeric target (e.g. 100 for 100%). Used to calculate progress.
current_value number EnrichingWhere are you today? Update regularly to keep the progress bar accurate.
In addition to the shared criteria:
Does the goal define a result whose achievement matters independently of completing planned activities?
Passes when: An outcome is distinguishable from completing activities.
Would movement in the selected metric constitute evidence of the intended outcome?
Passes when: Metric movement is meaningfully linked to the outcome under stated assumptions.
Can two independent reviewers calculate the metric consistently from the specified observations?
Passes when: Measure, population, and calculation yield comparable results.
Is there an unambiguous condition and timeframe for determining whether the goal has been achieved?
Passes when: Success condition and timeframe produce an unambiguous decision.
domain_modelThe territory we operate in — market landscape, key concepts, and boundaries
No type-specific fields.
In addition to the shared criteria:
Is the territory covered by the model distinguishable from adjacent territory?
Passes when: The domain boundary distinguishes included and adjacent territory.
Are central concepts defined precisely enough to distinguish their instances from non-instances?
Passes when: Central concepts have discriminating, consistent definitions.
Do the described relationships have an understandable meaning between the concepts involved?
Passes when: Relationships state understandable meanings between defined concepts.
Does the model name the use cases it serves and represent the concepts they need?
Passes when: The model names its use cases, and each can be expressed using the model.
Are contingent assumptions distinguishable from definitions and established observations?
Passes when: Contingent assumptions are explicit and distinguished from definitions and observations, or the model asserts none.
personaA research-backed representation of a core user
No type-specific fields.
In addition to the shared criteria:
Is the actor's operating context specific enough to constrain product decisions?
Passes when: Operating context imposes concrete design constraints.
Are the actor's desired outcomes distinguishable from proposed product features?
Passes when: Desired actor outcomes stand independently of features.
Do the described behaviors explain how the actor currently pursues their desired outcomes?
Passes when: Concrete current behaviors connect to the actor's outcomes.
Are relevant limitations or obstacles described concretely?
Passes when: Concrete limitations constrain how the actor can act.
Would the persona's characteristics support a design choice without relying on irrelevant stereotypes?
Passes when: Characteristics support specific design choices through relevant behavior or constraints.
problemThe core problem being solved and who it is for
No type-specific fields.
In addition to the shared criteria:
Does the problem identify a concrete gap between an existing condition and a desired condition?
Passes when: An existing and desired condition define a concrete gap.
Does the problem identify who experiences it and in what circumstances?
Passes when: Affected actors and triggering circumstances are explicit.
Does the problem explain why the gap matters to the affected actor?
Passes when: Concrete consequences explain the importance of the gap.
Would the problem remain intelligible if the proposed product or implementation were removed from the description?
Passes when: The problem is intelligible independently of a chosen solution.
Does the problem explain the limitations of current alternatives, including workarounds or inaction?
Passes when: Current alternatives and their relevant limitations are explained.
requirementAcceptance criteria that define when a project is complete
No type-specific fields.
projectA container for tasks and deliverables that advances a goal
No type-specific fields.
In addition to the shared criteria:
Do the acceptance clauses cover the artifact's material promised outcomes, relevant failure behavior, and scope boundaries?
Passes when: Clauses cover the material outcomes, relevant failure cases, and scope boundaries.
Can a reader distinguish included work from materially adjacent excluded work?
Passes when: Included and adjacent excluded work have a clear boundary.
Do milestones describe verifiable intermediate results?
Passes when: Milestones have observable intermediate completion conditions.
Does the proposed sequence respect identified prerequisites?
Passes when: Sequence respects prerequisites or explicitly establishes independence.
Can reviewers determine when the project has fulfilled its stated scope?
Passes when: Completion conditions cover the stated scope and are decidable.
architectureSystem architecture decisions, patterns, and technical design
No type-specific fields.
storyA user-facing narrative describing a feature or capability
estimate text EnrichingHow much effort is expected? (e.g. story points, t-shirt size)
ticketA trackable unit of work — bug, chore, or implementation task
ticket_type select CoreWhat kind of ticket is this?
Options: bug, chore, feature, spike
Tickets use their own criteria set instead of the shared criteria.
Do two obligations stated in the ticket conflict under the same conditions?
Passes when: No stated obligations conflict.
Does the ticket leave done undefined?
Passes when: A concrete, bounded change or research decision has an observable completion condition.
Apart from whether done is defined, does vague, promotional, or unexplained wording leave a material detail of the work, or an outcome it promises, to guesswork?
Passes when: Every material detail of the work is stated in concrete terms. A decision the ticket names as open, or a reference to code or another ticket, is not guesswork.
Does the title name the work without relying on outside context, such as a position in a parent's sequence?
Passes when: The title names the work itself and makes sense on its own.
Does each approval, sign-off, authorization, or decision the text relies on name who gave it or where it is recorded?
Passes when: Every approval or decision the text relies on names who gave it or links to where it is recorded, or the text relies on none.
When specifications are present, these criteria also apply:
Does the description promise a material outcome that no supplied acceptance clause covers?
Passes when: Acceptance clauses cover the material promised outcomes.
Can each clause be decided with an observable pass/fail result: for software, from a pull request's diff and its tests or a live performance run; for other work, from a stated record or observation? Judge the supplied clauses only, not completion checks the description lists. Rate the least verifiable clause.
Passes when: Each clause states an observable pass condition: a property a diff and tests or a live performance run can decide, or, for non-software work, a stated record or observation. A clause about code structure, repository configuration, registration, error handling, or runtime behavior that a test or code review can check is verifiable.
Is each acceptance clause consistent with the artifact's current description, without contradicting or distorting it? Clauses stand on their own: a clause may state an obligation the description does not mention. Concrete detail that carries out a described outcome, and a restatement of the description's own completion check, are faithful. A description of current or broken behavior states the problem, not an obligation, so a clause requiring the fix does not contradict it. Rate the least faithful clause.
Passes when: No clause contradicts or distorts the current description; a clause that restates a described obligation keeps its conditions. A clause stating an obligation the description does not mention is faithful.
Does every acceptance clause state a checkable obligation about the work, rather than a delivery step or a broken sentence?
Passes when: Every clause is a complete obligation about the behavior or properties of the work.