Hi Takahiro, thanks so much for this thoughtful comment. I’m glad the idea resonated with you.
The work has come from trying to break AI governance down into its “primitives”. I think this is important because not every project is going to need strict semantic compliance. It allows for you to understand what you’ll need to do to achieve your goals and pick the right strategies. That way, you’ll best understand the benefits and risks so you can choose the right guardrails.
My vision with it, to continue the healthcare analogy, is to develop a set of “clinical practice guidelines” for different types of projects. They would describe the best way to preserve semantic meaning and outline some of the known agentic pitfalls if they’re left to their own devices.
I hope that helps explain my thought process for you. Feel free to ask any follow-up questions if you want to keep chatting. Thanks again!
Yes! You have exactly the right idea. And I could not agree about semantic drift more. That’s why I really liked your Note about moving as much to deterministic mechanisms as possible.
The primitives are specific at the category/function level, but unspecified on purpose at the product level.
I am using this to create a large table of “nodes” (specific parts of a layer in the stack) and “edges” (where two specific parts of the same or different layer interact with each other).
For example:
Edge #45: “Identity/trust-root config influences what admission can regard as valid identity/authority”
This is general enough that if I want to switch from OpenCode to DeepSeek Harness, for instance, I know what edges I need to be looking for in that specific product.
Hope that makes sense. Since you’re actually in the field, I would love to chat with you more about how you decompose the problems. I can tell from your Note that you have a deep level of understanding about these things!
Hi Takahiro, thanks so much for this thoughtful comment. I’m glad the idea resonated with you.
The work has come from trying to break AI governance down into its “primitives”. I think this is important because not every project is going to need strict semantic compliance. It allows for you to understand what you’ll need to do to achieve your goals and pick the right strategies. That way, you’ll best understand the benefits and risks so you can choose the right guardrails.
My vision with it, to continue the healthcare analogy, is to develop a set of “clinical practice guidelines” for different types of projects. They would describe the best way to preserve semantic meaning and outline some of the known agentic pitfalls if they’re left to their own devices.
I hope that helps explain my thought process for you. Feel free to ask any follow-up questions if you want to keep chatting. Thanks again!
Yes! You have exactly the right idea. And I could not agree about semantic drift more. That’s why I really liked your Note about moving as much to deterministic mechanisms as possible.
The primitives are specific at the category/function level, but unspecified on purpose at the product level.
I am using this to create a large table of “nodes” (specific parts of a layer in the stack) and “edges” (where two specific parts of the same or different layer interact with each other).
For example:
Edge #45: “Identity/trust-root config influences what admission can regard as valid identity/authority”
Is composed of the interaction between
Node #24: “Identity / trust-root configuration”
and
Node #14: “Transition admission/pre-flight function”
This is general enough that if I want to switch from OpenCode to DeepSeek Harness, for instance, I know what edges I need to be looking for in that specific product.
Hope that makes sense. Since you’re actually in the field, I would love to chat with you more about how you decompose the problems. I can tell from your Note that you have a deep level of understanding about these things!