External Review Governance

Renma may eventually govern which external reviews are required and whether their evidence is current, complete, and applicable. Renma does not run, reproduce, or reinterpret those external reviews.

This document records the durable result of the completed two-producer concept experiment and the responsibility boundary for any future product work. It does not define a shipped CLI, metadata field, JSON schema, configuration contract, adapter SDK, plugin interface, or runtime behavior. Additional projection-shaping experiments are paused.

Completed Experimental State

The non-production research sequence evaluated three deliberately isolated steps:

1. The SkillSpector evidence-correlation experiment preserved scanner-native facts and correlated normalized source paths with Renma catalog assets only through exact repository-relative path matches. Unmatched, ambiguous, missing, and unsafe paths remained explicit. The executable-relationship extension added direct invocation and containment context from Renma's public executable graph as a separate layer. It did not turn those relationships into reviewed scope, scanner coverage, ownership, reachability, runtime execution, or safety claims.
2. The Cisco Skill Scanner evaluation evaluated Cisco as a second external-review producer, not as a second adapter. It exposed useful subject, execution, policy, analyzer, finding, assessment, and artifact evidence, while also exposing material output contract, reviewed-scope, component-content, and completeness gaps.
3. The deliberately unstable two-producer receipt concept tested whether both producers' evidence could be represented without translating producer semantics or manufacturing unavailable conclusions. It demonstrated an evidence-preserving conceptual envelope, not a production receipt or schema.

The receipt concept deliberately preserved unavailable and contradictory evidence as first-class. For example, Cisco's native JSON omitted its producer version, its native SARIF reported a version that contradicted the externally verified installation, and neither report format supplied the missing scope or completeness contract. The experiment retained those distinctions rather than selecting a convenient value or treating absence as success.

Experimental Result

Common Governance Concepts

Both producers raised a useful common set of governance questions:

• which producer and report contract supplied the evidence;
• which logical subject the review concerns;
• which components and exact content were actually reviewed;
• whether producer execution completed;
• which assessment profile, analyzer set, policy, baseline, or suppression context applied;
• what the producer reported about completeness, limitations, and unavailable work;
• which native findings and native assessment the producer emitted;
• which exact artifact was preserved;
• whether the evidence is current; and
• whether a separately defined Renma review requirement is satisfied.

These are common conceptual dimensions, not common field names or interchangeable values. SkillSpector and Cisco retain different rule models, severity scales, finding identities, completeness evidence, policy semantics, and assessment meanings. Their native findings and assessments can and should remain producer-specific. No common finding taxonomy, severity conversion, score, verdict, deduplication key, or safety meaning was established.

The experiment therefore resolves the former question of whether a second producer makes provider-neutral concepts useful: the concepts are useful for asking governance questions across both producers. It does not establish that a provider-neutral production receipt, parser, adapter, schema, or framework is ready or necessary.

Binding, Relationships, And Artifact Integrity

A logical subject and its exact reviewed scope are different evidence. Exact catalog correlation can identify a Renma asset without proving which support files the producer reviewed or which bytes it inspected. A producer-listed component path is not content binding without component-content evidence. A repository revision or independently observed file set is useful provenance, but it cannot repair a native report that omits its reviewed component set.

Executable invocation and containment relationships remain separate from reviewed scope. They can add repository context to an exactly correlated file finding, but they do not prove that a related Skill or script was inspected, affected, reachable at runtime, or covered by the producer.

An exact report digest is useful only for artifact integrity: it identifies the bytes that were preserved. It does not identify a logical subject, provide component-content binding, prove semantic equivalence across runs, establish freshness or completeness, or support a safety conclusion. The Cisco evaluation also observed repeat reports whose raw digests differed because of volatile timestamps and durations while their other observed content remained the same.

Completeness And Required Profiles

Three concepts must remain separate:

producer-native completeness
  The external reviewer's own completeness, status, coverage, limitations,
  skipped work, failures, and unavailable or inapplicable work.

required-profile completeness
  Whether all review work required by an independently defined Renma profile
  completed for the bound subject and scope.

requirement satisfaction
  A future governance conclusion that also depends on valid binding,
  freshness, required-profile completeness, and native assessment evidence.

Producer-native completeness must be preserved without reinterpretation. SkillSpector serialized a richer component and analyzer ledger, including a native incomplete result in the captured case. Cisco did not serialize a comparable planned, completed, skipped, failed, unavailable, or not-applicable work ledger. Successful execution, a favorable native assessment, or a high coverage value cannot repair incomplete or unavailable evidence.

Renma has not designed a required external-review profile. Any future profile would need an independently reviewed identity and digest-bound definition of the required work. Until that exists, required-profile completeness and requirement satisfaction cannot be derived from either producer's native assessment.

Responsibility Boundary

The responsibility boundary remains unchanged:

flowchart LR
  Reviewer["`External reviewer
native inspection + assessment`"]
  Native["Published native evidence"]
  Repository["Public Renma repository evidence"]
  Adapter["`Possible future companion adapter
preserve + bind`"]
  Bound["Possible future bound evidence"]
  Reviewer --> Native
  Native --> Adapter
  Repository --> Adapter
  Adapter --> Bound

External reviewer
  - performs native inspection
  - owns native findings, severities, scores, and assessment
  - owns native execution coverage, suppressions, and limitations

Possible future separately installed adapter
  - consumes only a trustworthy, supported published report contract
  - preserves producer-native evidence and provenance
  - binds published evidence to stable public Renma repository evidence
  - retains unavailable, contradictory, and producer-specific evidence

Renma core
  - owns its existing repository identity and deterministic governance checks
  - does not run external scanners
  - does not load adapters or depend on review producers
  - does not translate native findings into Renma findings or diagnostics
  - does not reproduce producer assessment logic or infer safety

A future adapter would be a companion tool, not a plugin loaded into Renma core. It could preserve and bind published evidence only after the applicable producer contract and binding evidence are trustworthy. Cisco was the second evaluated producer, not a second adapter; no production adapter exists, and the experiment does not justify an adapter SDK, registry, or generic framework.

Any future adapter must fail closed on unsupported output versions and avoid rescanning source, deciding whether findings are correct, suppressing findings with an LLM, translating native rule IDs, modifying repository assets, reproducing a producer's risk algorithm, or adding the producer as a Renma dependency.

Stable Requirements And Generated Evidence

Authored governance intent and generated external-review evidence remain different artifacts. A future stable declaration could identify a required review category or profile only after Renma independently designs that contract. A generated report would then provide evidence about one producer execution over a bound subject and scope. Producer results must not be stored as authored Renma metadata because they become stale when content, producer version, profile, policy, baseline, suppression context, or execution mode changes.

This direction adds no review-requirement metadata field and proposes no field layout. The current compatibility behavior for unknown string-valued renma.* keys does not make scanner-result keys operational, documented, or recommended Renma metadata.

Relationship To Existing Renma Evidence

The Repository Context BOM remains a declared repository manifest. Public catalog, BOM, and executable-graph evidence can provide independent repository identity and relationships, but they cannot manufacture facts omitted by a producer. In particular, Renma content hashes do not become producer-observed component hashes merely because the same path appears in both systems.

Generated external-review evidence remains separate from BOM v2, the Trust Graph, Readiness, diagnostics, and CI policy. This direction does not create a catalog asset kind, dependency edge, coverage relationship, security finding family, or runtime input.

Renma continues to own its bounded deterministic checks over repository declarations and agent-facing instructions. Specialized external tools remain responsible for their native executable-code, taint, dependency, supply-chain, malware, least-privilege, tool-poisoning, and semantic inspections. Neither kind of evidence proves runtime behavior. A clean external report does not prove that a Skill is safe, and passing Renma checks means only that the enabled deterministic governance checks passed.

Production Blockers And Pause

The two-producer concept did not justify production implementation. Work remains blocked by:

• producer output and version contracts that are not yet trustworthy enough for fail-closed parsing;
• the inability to bind the exact producer-reviewed component set;
• missing producer-bound component-content evidence;
• incomplete serialized completeness, limitation, skipped-work, failure, and applicability evidence; and
• the absence of an independently designed, named, digest-bound Renma required review profile.

Another projection-shaping experiment would rearrange unavailable evidence without removing those blockers. Such experiments are paused.

Revisit the concept only when at least one of these bounded conditions materially changes the evidence:

• a producer publishes a trustworthy, versioned report contract;
• complete reviewed-component identity or content binding becomes available;
• serialized completeness and limitation evidence materially improves;
• Renma independently designs a required review profile; or
• a third producer exposes a genuinely new evidence shape.

A revisit is permission to reassess the concept, not a commitment to ship it. There remains no commitment to a production receipt, parser, adapter, public schema, framework, metadata field, configuration field, CLI behavior, diagnostic, Readiness input, CI policy, BOM or Trust Graph change, dependency, package content, package version, or release.

LLM proposes. Renma verifies. Human approves.