Build above shared meaning
Profiles, vendor layers, and business context
Core supplies a common investigative model. Public domain profiles add reviewed vocabulary, questions, and requirements. Vendor layers provide tooling and integrations. Business layers supply explicit policy, authority, thresholds, and organizational context.
Each can specialize an investigation. None may silently redefine a Core outcome, change a question's proposition under the same identity, or turn a policy judgment into an observation.
Publish the semantic dependency
- Give profiles and extension definitions an identity and version.
- Declare constraints, dependencies, and whether an extension is required for interpretation.
- Expose unsupported required meaning instead of returning a misleading successful interpretation.
- Preserve unknown optional data when claiming lossless exchange.
- Use explicit binding parameters or a new definition identity when local behavior changes a question's meaning.
Follow the extension representation in the candidate binding. The logical proposal does not make arbitrary vendor key names interoperable.
Keep policy visible
A question about whether a tool call exceeded its permitted scope needs the relevant policy version and context. A risk score may support a decision if its scale, method, and interpretation are stated. A private score or hidden prompt cannot silently replace public assessment criteria.
Record claimed authority separately from attribution. A human, agent, system, or organization label alone grants no permission. Importing a record neither authorizes an action nor permits access to referenced evidence.
Report exchange limits
A vendor-specific ticket layout may be optional display metadata. A dependency that changes the interpretation of a decision is not. When a recipient cannot interpret required semantics, its report must identify the affected content. When an export drops content, declare the loss.
Read requirements TC-29 through TC-35 · Validation and exchange evidence