Consider more opinionated sub-entities - problem statement, risk, assumption, insight, decision, principle

[mindsocket]

These wouldn't be full pages, but these things should be attached to OST nodes during product lifecycle.

Explore whether a structured entity type makes sense to define. Consider:

• Pure AI assisted extraction of information from a page to populate a structure
• Semi-structured conventions and templates for expressing these within a node/page (eg a risk table with a format matching the schema), potential validation helpers
• Instead of a structured schema, define a set of descriptive goals, rules and activities that teams and agents can work from
• Something else?

[mindsocket]

Following research on #3 (findings in docs/torres-alignment-research.md):

A few refinements from the research:

Full page vs embedded is intentionally flexible. A schema defines an entity type (e.g. assumption, metric) in one place. Both a full-page file and an embedded heading within a primary entity page are valid expressions of that type — once #10 lands. The question of "should this be its own page?" is a content organisation decision, not a schema constraint.

Metric as a sub-entity attribute, not a standalone type. Rather than a new metric entity type, consider metric as a structured annotation on a goal or opportunity — a field or inline section with a defined shape. This keeps the entity hierarchy lean. A composable schema building block (#17) could define what a well-formed metric looks like for teams that want to enforce it.

Assumption and the fourth layer. Research confirms that Torres' bottom layer (assumption test) maps naturally to the sub-entities in this issue. For lightweight planning, assumptions can be inline sections on a solution page. For teams doing full discovery, they earn their own files. The same entity schema covers both. A fourth-layer entity type is being added to the general schema in #14.

[mindsocket]

This is becoming an overarching goal for being able to manage more structured information within a page.

That would suggest it involves some combination of #26 #27 #31 #17 .

Imagining these things combined...

• An opportunity page might have a heading with a problem statement. Because of defining natural language we can tell which section is the problem statement and parse it
• The same page might have a list of assumptions. Because we can parse tables, a table of assumption entities with attributes can be parsed from the page too.
• The template-sync knows how to make an opportunity page with the requisite sub-elements listed. This is because something in the schema metadata indicates the non-hierarchy entities (ie adjacent relationships) there are and how the should be rendered into a template. - eg assumptions are a table, with columns for the title and any required properties. problem statements are a heading. solutions are a bulleted list (and also happen to be part of the core hierarchy. Any of these can also be their own page if needed.