Future exploration: generic Profile platform and profile-aware tooling

[chrishiguto]

Why this is deferred

The Concepta OKF Profile is valuable as one company-wide, versioned policy for using OKF consistently. A generic Profile platform is a different product: it introduces extension, distribution, trust, execution, and lifecycle contracts that are not justified by the one real Profile we have today.

The first implementation should prove the smaller outcome:

• okf remains an independent, OKF-only toolkit and CLI.
• The Concepta OKF Profile remains a normative delta over the pinned OKF Specification.
• okfp composes the closed OKF result with a closed set of deterministic Concepta Profile checks.
• Judgment-heavy conventions are taught and reviewed through skills and guides; the CLI does not claim to prove them.
• The bundle selects the Concepta Profile release through profile.md; it cannot configure the release's rules.

A public abstraction should be extracted from multiple real implementations, not designed from one hypothetical adapter. Building it now would make the interface nearly as complex as the machinery behind it while delaying the validator Concepta actually needs.

Deferred exploration

Revisit, but do not include in the first implementation:

• A public generic Profile protocol.
• Third-party Profile providers.
• Executable rule registries.
• Caller-selected rule activation.
• A standalone Profile Definition YAML.
• Suppressions, until a real migration proves they are needed.
• Profile-aware MCP writes.
• Profile-owned filesystem transactions.
• Claims that every judgment-heavy convention is mechanically provable.

Why each concern waits

• Generic protocol and providers: only the Concepta Profile exists. A second independently designed Profile is needed to reveal the genuinely shared interface.
• Registries and rule activation: the first Concepta release needs one immutable rule set, not runtime composition. Public activation creates drift between bundles claiming the same release.
• Standalone Profile Definition YAML: the normative document and its compiled rules already define the release. Another representation risks becoming a second source of truth unless generation proves necessary.
• Suppressions: their governance, expiry, and relationship to conformance should be designed from an actual adoption that cannot proceed without them.
• Profile-aware MCP writes and transactions: OKF owns generic bundle management. A concrete Profile-aware authoring workflow must first prove what orchestration is missing.
• Mechanical proof of judgment: rules such as whether a directory names the true shared subject of its concepts require contextual judgment. Skills and guides can teach and review them; a deterministic CLI must not overclaim.

Revisit triggers

Reopen architectural design only when at least one of these is true:

1. A second real, independently owned OKF Profile needs to run through the same tooling.
2. A real migration cannot adopt the Concepta Profile without governed suppressions.
3. A concrete agent workflow demonstrates that OKF writes plus Concepta guidance cannot safely produce a conformant candidate.
4. Two implemented Profile validators reveal a stable common rule or provider interface.
5. A machine-readable Profile Definition can be generated from, or made authoritative over, the normative release without dual-source drift.

Questions for that future design

• Which behavior is genuinely common across two Profiles?
• Which rules are declarative, which require provider code, and which remain judgment?
• How are providers authenticated, versioned, installed, and isolated?
• What result can tooling truthfully claim when required judgment is unevaluated?
• Which write behavior belongs generically in okf, and which orchestration is Profile-specific?

Superseded planning

This exploration replaces the generic-platform premises in #3 and its slices #5–#13. It also supersedes the stale dependency-cleanup task #16. Those issues are being closed as obsolete, not completed.

[chrishiguto]

Not executed in this delivery. This issue is intentionally deferred until one of its listed revisit triggers exists (for example, a second independently owned Profile or a migration that proves suppressions are necessary). The 2026.2 work instead ships the closed Concepta validator specified in #21; creating a PR here now would reintroduce the speculative platform scope this issue isolates.