UNDER CONSTRUCTION
1. Summary (Required)
What is the enhancement?
Provide a short and clear description of the improvement.
2. Problem Statement (Required)
How can we remove the barriers to rapid iteration on holonic types without losing the validation and governance of their underlying schema definitions?
Holonic Types is an emerging pattern. These are structs that:
- embed a (ideally typed) HolonReference to a holon that manages state
- offer a set of methods that expose its type-specific behavior
This pattern allows us to bridge the world of extensible, self-describing active holons with the statically-typed (and therefore compiler-validating) world of Rust for MAP core.
The types methods make strong assumptions about the properties, relationships, and behaviors this type affords. These assumptions take the form of enumerated type names that are used as parameters to generic reference-layer functions. For example, property_value requires a PropertyName and related_holons requires a RelationshipName.
Thus, the introduction and evolution of these holonic types depends on:
- the schema definition of those types
- the inclusion of those schema definitions in the core schema's import files
- the extension of the core schema's type name definition
Current Process
The current process puts Rashaan on the critical path for steps 3, 4, and 5 and Steve (as PR Reviewer) for 6. So even simple changes can take days. Those delays hit right during the most volatile stages of design and implementation when rapid iteration is most important. These barriers to iteration affect delivery velocity and design quality. They also create a negative DX that can hamper recruitment and lengthen the core dev learning curve.
Additionally, the core schema source of truth (Airtable) is outside of GitHub and its version control system
3. Dependencies (Required)
None
4. Proposed Solution (Required)
How would you solve it?
Explain your idea. It doesn’t need to be perfect—just enough to guide a discussion.
5. Scope and Impact (Required)
What does this impact?
Outline what parts of the system, user workflows, or broader ecosystem are affected.
6. Testing Considerations (Required)
How will this enhancement be tested?
- Can it be validated with existing test cases?
- Do new test cases need to be created?
- Are there specific areas in the test ecosystem impacted by this enhancement?
7. Definition of Done (Required)
When is this enhancement complete?
Provide clear criteria to know when the enhancement has been fully implemented and validated.
Optional Details (Expand if needed)
8. Alternatives Considered
What other solutions did you think about?
Briefly describe alternatives and why this approach is preferred.
9. Risks or Concerns
What could go wrong?
Highlight potential challenges, like performance or compatibility issues.
10. Additional Context
Any supporting material?
Include links, screenshots, logs, or diagrams.
UNDER CONSTRUCTION
1. Summary (Required)
What is the enhancement?
Provide a short and clear description of the improvement.
2. Problem Statement (Required)
How can we remove the barriers to rapid iteration on holonic types without losing the validation and governance of their underlying schema definitions?
Holonic Types is an emerging pattern. These are structs that:
This pattern allows us to bridge the world of extensible, self-describing active holons with the statically-typed (and therefore compiler-validating) world of Rust for MAP core.
The types methods make strong assumptions about the properties, relationships, and behaviors this type affords. These assumptions take the form of enumerated type names that are used as parameters to generic reference-layer functions. For example,
property_valuerequires aPropertyNameandrelated_holonsrequires aRelationshipName.Thus, the introduction and evolution of these holonic types depends on:
Current Process
The current process puts Rashaan on the critical path for steps 3, 4, and 5 and Steve (as PR Reviewer) for 6. So even simple changes can take days. Those delays hit right during the most volatile stages of design and implementation when rapid iteration is most important. These barriers to iteration affect delivery velocity and design quality. They also create a negative DX that can hamper recruitment and lengthen the core dev learning curve.
Additionally, the core schema source of truth (Airtable) is outside of GitHub and its version control system
3. Dependencies (Required)
None
4. Proposed Solution (Required)
How would you solve it?
Explain your idea. It doesn’t need to be perfect—just enough to guide a discussion.
5. Scope and Impact (Required)
What does this impact?
Outline what parts of the system, user workflows, or broader ecosystem are affected.
6. Testing Considerations (Required)
How will this enhancement be tested?
7. Definition of Done (Required)
When is this enhancement complete?
Provide clear criteria to know when the enhancement has been fully implemented and validated.
Optional Details (Expand if needed)
8. Alternatives Considered
What other solutions did you think about?
Briefly describe alternatives and why this approach is preferred.
9. Risks or Concerns
What could go wrong?
Highlight potential challenges, like performance or compatibility issues.
10. Additional Context
Any supporting material?
Include links, screenshots, logs, or diagrams.