RFC: define governed extension points for context generation and custom Artifacts

Feature description

Define governed extension points for customizing context generation and introducing new derived Artifact families without forking PowerContext.

The first slice should let an administrator register a versioned generation profile and one typed derived Artifact extension while preserving exact evidence, schema validation, Review policy, authorization, resource bounds, and Runtime-owned context composition.

Problem and proposed solution

Organizations may want to change how a proposal is generated or create a domain-specific result such as a runbook, incident brief, requirement decision, or support resolution. Today the safe extension choices are narrow: callers can provide Sources and use built-in Memory, Experience, Skill, and Handoff behavior. Allowing arbitrary hooks inside the Runtime would make model output, storage, injection, and authority difficult to reason about.

The RFC should define two separate extension surfaces:

1. Versioned generation profiles

• profile identity and immutable revision;
• model/provider requirements and bounded settings;
• Prompt Template identity, input schema, output schema, and content limits;
• exact Source/Artifact evidence inputs;
• timeout, retry, cost, and failure behavior;
• generated output always enters the owning Family's Draft/Candidate path and never commits itself.

2. Derived Artifact family extensions

• globally unique family ID, schema version, content model, and migration rules;
• fixed review policy and explicit lifecycle actions;
• exact lineage and immutable Revision semantics;
• search/index projection declared separately from authority;
• optional PreparedContext rendering/contribution that requires separate registration, budget, trust envelope, and authorization;
• installation and compatibility through an administrator-controlled package boundary, not public remote-code upload.

The extension API must not expose database sessions, internal repositories, unrestricted filesystem/network access, or a way to alter built-in identity and transaction invariants.

Acceptance criteria

• One sample extension can derive a typed Candidate from exact evidence, pass human Review, and commit an immutable Artifact Revision.
• Changing a Prompt, model, settings, schema, or extension package creates a new exact profile/extension version visible in lineage.
• Invalid or unavailable extensions fail before persisting a Candidate and do not block unrelated Runtime capabilities.
• A generator cannot allocate final Artifact identity, approve its Candidate, publish/install content, or grant itself execution authority.
• A custom Artifact is not searchable or injectable until its projection and PreparedContext behavior are explicitly registered and authorized.
• PreparedContext remains bounded, cited, and wrapped as untrusted history; an extension cannot inject raw system/developer instructions.
• Extension execution has explicit time, memory, output, network, and secret policy, with content-free diagnostics.
• OpenAPI, SDK, MCP, Dashboard, and generated Agent transports expose only the reviewed public operations required by the accepted RFC.

Alternatives considered

• Arbitrary Python callbacks configured at runtime: powerful but unsafe, unversioned, and difficult to support remotely.
• Let prompts return untyped JSON stored directly in one generic table: erases Family semantics, lifecycle, review, and compatibility.
• Treat every new result as Memory: conflates durable facts/decisions with domain-specific deliverables.
• Let custom output enter PreparedContext automatically: bypasses selection, citation, budget, trust, and authorization policy.

Additional context

This issue is separate from the Source Connector SDK: connectors produce Source observations; generation and Artifact extensions transform exact evidence into governed derived results. Related: #1240, #1363, #1395, and #1397.

• I am willing to contribute code, docs, or design feedback.