The kinetic envelope shipped with a ROS2 reference profile and seven vectors
(#242, #245). Reading back over it, the thing that stands out is that the
conformance surface covers ROS2 and the bridge surface is mostly MCP.
That is the gap I would want to close if it were my repo, so: would a
software-substrate profile be useful to you, and would you want it from me?
The case for it, in your terms rather than mine —
It lands on the surface your users are actually on. The README leads with
"AI agents, MCP tools" and the breach evidence you cite is MCP's ten incidents in
eight months. Right now a reader who arrives through the MCP bridge finds an
envelope that only has vectors for robots.
It makes the interface substrate-general rather than robotics-specific. One
profile is a feature for one domain. A second profile, in a domain that shares
nothing physical with the first, is evidence the interface was the right shape.
That is a stronger claim for the spec than either profile alone, and it belongs
to SINT either way.
The magnitudes are the interesting part. ROS2 has velocity, force, torque,
angular velocity. A software agent has none of those, so the profile declares its
own set. On the KTP side that set is privilege, reachability, irreversibility,
credential reach and configuration reach — authority the acting process holds,
how far the action extends beyond it, the cost of undoing it, the secret material
it touches, and the future behaviour it changes. That set came out of a second
KTP implementation on a software substrate, so it arrives already exercised
rather than invented for this.
Whether TightenedConstraints needs another field to carry them is exactly what
writing the vectors would tell us, and it is cheaper to find out now than after a
third profile.
What I would produce, if you want it: a software-agent-reference-v0.1.json in
the same shape as yours — a safe action, a self-check escalation, two
capacity-driven escalations, a veto, and an unknown-capacity clamp — plus
whatever the profile section needs in the spec README. Same normative fields.
Nothing that changes gateway behavior.
Two questions before I write anything.
Is step 4 still the plan? The spec ends with wiring supervision into
assignTier as a floor once the vectors pass. That is the step where the
envelope actually governs something, and I did not want to add surface area
ahead of it if your sequencing has moved.
Do you want this as a PR, or would you rather own the profile and take the
vectors as input? It is your spec and your conformance surface — I am happy
either way, and I would rather ask than assume.
One thing worth saying plainly: the reference profile, the seven vectors and the
harness are yours, and the vector design is the part I would copy rather than
improve on. The unknown-capacity clamp in particular — forcing a safe-looking
margin to assisted because the trajectory is novel — is the case most people
would have left out.
The kinetic envelope shipped with a ROS2 reference profile and seven vectors
(#242, #245). Reading back over it, the thing that stands out is that the
conformance surface covers ROS2 and the bridge surface is mostly MCP.
That is the gap I would want to close if it were my repo, so: would a
software-substrate profile be useful to you, and would you want it from me?
The case for it, in your terms rather than mine —
It lands on the surface your users are actually on. The README leads with
"AI agents, MCP tools" and the breach evidence you cite is MCP's ten incidents in
eight months. Right now a reader who arrives through the MCP bridge finds an
envelope that only has vectors for robots.
It makes the interface substrate-general rather than robotics-specific. One
profile is a feature for one domain. A second profile, in a domain that shares
nothing physical with the first, is evidence the interface was the right shape.
That is a stronger claim for the spec than either profile alone, and it belongs
to SINT either way.
The magnitudes are the interesting part. ROS2 has velocity, force, torque,
angular velocity. A software agent has none of those, so the profile declares its
own set. On the KTP side that set is privilege, reachability, irreversibility,
credential reach and configuration reach — authority the acting process holds,
how far the action extends beyond it, the cost of undoing it, the secret material
it touches, and the future behaviour it changes. That set came out of a second
KTP implementation on a software substrate, so it arrives already exercised
rather than invented for this.
Whether
TightenedConstraintsneeds another field to carry them is exactly whatwriting the vectors would tell us, and it is cheaper to find out now than after a
third profile.
What I would produce, if you want it: a
software-agent-reference-v0.1.jsoninthe same shape as yours — a safe action, a self-check escalation, two
capacity-driven escalations, a veto, and an unknown-capacity clamp — plus
whatever the profile section needs in the spec README. Same normative fields.
Nothing that changes gateway behavior.
Two questions before I write anything.
Is step 4 still the plan? The spec ends with wiring
supervisionintoassignTieras a floor once the vectors pass. That is the step where theenvelope actually governs something, and I did not want to add surface area
ahead of it if your sequencing has moved.
Do you want this as a PR, or would you rather own the profile and take the
vectors as input? It is your spec and your conformance surface — I am happy
either way, and I would rather ask than assume.
One thing worth saying plainly: the reference profile, the seven vectors and the
harness are yours, and the vector design is the part I would copy rather than
improve on. The unknown-capacity clamp in particular — forcing a safe-looking
margin to
assistedbecause the trajectory is novel — is the case most peoplewould have left out.