joaohenrique/jhonny-editor
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: initial commit - Jhonny Editor

Browse Source 
- Adicionado estrutura completa do projeto
- Configurado MCP server para Premiere Pro
- Adicionado documentação e skills
- Configurado Gitignore para o projeto
This commit is contained in:
João Henrique
2026-09-08 09:59:31 -04:00
commit b541f502ba
1507 changed files with 387650 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
code/docs/industry/host-validation-2026-08-22.md
Executable
+60
View File
@@ -0,0 +1,60 @@
# Project Intake host-validation record
Date: 2026-08-22
Platform: Windows 11
Host: Adobe Premiere Pro 2026
Candidate: 1.13.0
## Scope
Validate the preview-only `preview_project_intake` tool through the installed
CEP bridge without opening or modifying an existing editorial project.
## Setup
- Created a disposable empty Premiere project under the repository's ignored
`test-results` directory.
- Confirmed the project file was written (5,103 bytes).
- Ran `node dist/index.js --diagnose-cep`; the installed connector passed its
filesystem and configuration checks.
- Did not open the existing recent project or import user media.
## Result
Blocked before MCP execution. Premiere became unresponsive while entering the
editing workspace for the disposable project. The same behavior recurred after
terminating only the hung Premiere process, restarting Premiere, and reopening
only the disposable project. The CEP panel could not be opened, so no bridge
command and no `preview_project_intake` call ran.
## Evidence boundary
- Connector installation diagnosis: passed.
- Deterministic engine and MCP handler automated tests: passed in the release
worktree.
- Real Premiere/CEP tool execution: not demonstrated.
- Project mutation, media import, render verification, save/reopen verification,
and macOS host coverage: not performed.
This record is failure evidence for the host gate, not evidence that Project
Intake works in Premiere 2026.
## 2026-08-23 follow-up
- Audited the public `v1.13.0` GitHub release connector before installation.
Its SHA-256 was
`583949dd0decd5ed91478ce3c39a75c67512b5b06ac6d1db712eb03ee9701bf7`,
and its embedded CEP manifest reported `1.13.0`.
- Installed that exact signed connector and confirmed the local installer
diagnosis passed.
- Adobe Premiere Pro 2026 opened the disposable project and rendered the empty
editing workspace, but became unresponsive when the Window menu was invoked.
No CEP panel command or MCP tool call completed.
- Adobe Premiere Pro (Beta) opened the same fixture through its required
conversion flow into a separate disposable copy. The converted project then
stalled on a black editing canvas before the CEP panel could be opened.
The repeated host failure now covers the stable and Beta applications with the
audited signed connector. It still does not demonstrate a
`preview_project_intake` execution, and it does not justify a real-host support
claim for this workflow.
code/docs/industry/project-intake-workflow.md
Executable
+557
View File
@@ -0,0 +1,557 @@
# Project Intake Assistant contract
**Contract ID:** `INDUSTRY-01`
**Version:** `0.1.0-draft`
**Status:** proposed product contract; not a production-readiness claim
**Last reviewed against source tree:** 2026-08-22
## Purpose and implementation status
Project Intake Assistant is a bounded, assistant-editor workflow for inspecting
media that is already in a Premiere project, proposing deterministic
organization and metadata changes, applying only an approved subset, and
recording what is known about the result. It is deliberately a workflow around
existing MCP actions, not a claim that an AI can make editorial decisions.
There is **no current `project_intake` MCP tool, facility-template schema, or
production-ready end-to-end intake workflow** in this repository. This document
is the contract for building one. The current source provides useful, narrower
building blocks:
- `verify_premiere_connection` is a read-only connection check that avoids
returning project names, paths, and media details.
- Authenticated UXP discovery is capability-gated at the connected host; a
failed UXP command must not silently fall back to CEP or QE.
- The authenticated UXP surface can inspect a compact revisioned project
snapshot, Project-panel selection, bounded media health, proxy/ingest state,
metadata, and project/Production storage state. It also has guarded project
item organization and a reviewed organization-plan apply route.
Those are current source capabilities with their own limits, not evidence that
they work in every licensed Premiere build. See the [supported-actions
catalog](../supported-actions.md), [UXP capability foundation](../uxp-capability-foundation.md),
[stable workflow matrix](../uxp-stable-workflows.md), and [editorial workflow
host-validation runbook](../editorial-workflow-host-validation.md).
In this contract, **Current** means implemented in the source tree and
documented at the linked repository reference. **Proposed** means a required
addition for Project Intake; it must not be advertised as callable or
production-ready until it passes the acceptance gates below.
## Scope
### In scope
The first implementation MUST support a selected, explicit set of project
items in one connected project. It MAY propose only these classes of work when
the connected host advertises the necessary capability:
1. Read-only readiness checks: connection, host capability, active-project
identity, project snapshot revision, Project-panel selection, bounded media
health, proxy/ingest state, metadata state, and storage preflight.
2. Deterministic facility rules: expected bin destination, allowed color label,
naming pattern, and allowlisted metadata fields.
3. Review-only organization plans that identify exact project-item IDs and
expected parent IDs.
4. Explicitly approved bin creation, moves, color labels, and allowlisted
metadata updates through documented UXP operations.
5. A redacted operation receipt with per-operation certainty and recovery
instructions.
The workflow MUST begin read-only. A template check whose required host field is
not exposed by the selected capability MUST report `unsupported` or
`not_inspected`; it MUST NOT be inferred as a pass.
Frame-rate evidence follows the same fail-closed rule. A non-finite or out-of-range
host value becomes an item-level `FRAME_RATE_UNSUPPORTED` finding and makes the
report incomplete; it does not abort inspection of unrelated items. Valid decimal
readings are matched after snapping values within 0.005 fps of a canonical timebase,
then using a maximum 0.05 fps tolerance for non-canonical Premiere measurements.
Canonical rates such as 23.976 and 24 remain distinct.
### Non-goals
Project Intake v0.1 MUST NOT:
- choose story, selects, pacing, or any other editorial judgment;
- import arbitrary files, scan disks, or treat a filesystem folder as the
intake scope without a separate approved, workspace-gated import contract;
- inspect codecs, frame rates, audio-channel layouts, timecode, duplicate
media, or proxy completeness unless the exact source field and its real-host
support are added to the capability matrix;
- change a timeline, create a rough cut, replace media, relink media, attach a
proxy, change ingest state, configure scratch disks, delete an item, or save
a project as part of ordinary intake;
- call a generative, transcription, translation, cloud-analysis, or media
upload provider;
- use filenames, a model guess, or a non-unique display name as mutation
authority;
- claim atomic cross-command rollback, visual correctness, rendered-output
correctness, copyright clearance, or production readiness.
Some excluded operations are separately exposed by the current UXP surface
(for example proxy attachment, relink, and storage configuration), but have
their own confirmation, workspace, non-undo, or verification boundaries. They
are intentionally outside this contract. See [supported actions](../supported-actions.md)
and [local-first editorial workflow boundaries](../ai-editorial-workflows.md).
## Personas and authority model
| Actor | May do | Must not do |
| --- | --- | --- |
| Assistant editor (operator) | Select the intake scope, review findings, edit the proposed plan, approve or reject a concrete plan, inspect the receipt. | Approve a plan on behalf of another person or bypass a stale-plan check. |
| Post supervisor (workflow owner) | Publish an approved template version, decide the permitted operation classes, review exceptions and pilot evidence. | Treat a receipt as proof of picture, sound, or delivery quality. |
| Facility administrator | Configure local bridge installation, approved workspace policy, identity/role integration, and retention policy. | Put secrets, native paths, media names, or transcripts into persistent workflow checkpoints. |
| MCP client / model | Request inspection and construct a plan strictly from the template and returned evidence. | Create its own template, self-approve, invent targets, or treat a recommendation as mutation authority. |
| UXP bridge / Premiere host | Advertise capabilities, execute a documented operation, and return its command-specific readback. | Establish licensed-host validity, visual quality, or an unexposed postcondition by itself. |
**Proposed authority rule:** `inspect` requires read authority and an
authenticated, connected host where UXP data is used. `plan` and `preview` are
non-mutating. `confirm` requires an attributable human identity plus the exact
plan digest. `apply` requires `edit` authority, a current host capability
attestation, the same project identity/revision, and an unexpired confirmation.
Only the UXP route is eligible for Project Intake mutations. CEP/QE fallback is
forbidden even if a similarly named legacy action is available.
The existing reviewed organization route already uses server-issued plan and
preview-confirmation material, stable source/parent guards, and UXP-only bin
transactions; it reports partial completion instead of rolling back a prior
bin creation. Project Intake MUST preserve those semantics rather than wrap
them in an "all-or-nothing" claim. See [local-first editorial workflows](../ai-editorial-workflows.md)
and [`apply_editorial_organization_plan`](../supported-actions.md).
## Required state machine
Each request has one immutable `requestId`; each planned mutation has a unique
`operationId`. A state transition is append-only in the proposed receipt ledger.
The only mutation state is **Apply**.
```text
Inspect -> Plan -> Preview -> Confirm -> Apply -> Verify -> Receipt
| | | |
+-> Reject +-> Expire +-> Stop -+
```
| State | Required behavior | Mutation allowed? |
| --- | --- | --- |
| **Inspect** | Verify the intended backend, collect only capability-supported evidence, resolve stable target IDs, and capture project/revision locks. | No |
| **Plan** | Evaluate the immutable template against the inspection snapshot. Produce explicit findings and individual candidate operations. | No |
| **Preview** | Re-inspect the target project and guards, calculate a canonical plan digest, show before/after intent and limitations, then issue an opaque confirmation token. | No |
| **Confirm** | Record an identifiable human's explicit approval of the exact template version, plan digest, target project, and expiry. Any edit creates a new plan. | No |
| **Apply** | Re-check host capability, project identity/revision, confirmation, and every operation guard immediately before dispatch. Execute bounded operations; do not auto-retry an uncertain commit. | Yes, only the approved operations |
| **Verify** | Reinspect the exact host state exposed for each completed operation. Classify each result with a certainty state; stop on an unknown mutation or policy-defined failure. | No new mutation |
| **Receipt** | Persist or return a privacy-redacted, append-only record of the plan, approvals, results, certainty, evidence references, and recovery instructions. | No |
### Preconditions and stop conditions
The workflow MUST stop before mutation when any of the following is true:
- no active authenticated UXP bridge or the required command is not advertised;
- the selected project cannot be identified by a stable host project ID/GUID;
- the active project changed after Inspect or Preview;
- the current project/context revision differs from the preview lock;
- the template version/digest, plan digest, confirmation token, operator
identity, or policy scope differs from the approved value;
- any target resolves to zero or multiple project items, or lacks an expected
parent guard for a move;
- a confirmation expires, is rejected, or is not attributable to a human;
- an operation would be outside the template's permitted operation types or
metadata allowlist.
The current project-context and editorial-plan foundations already reject stale
context/timeline revisions and keep review receipts separate from mutation
authority. Their snapshot is a useful input, but it does not prove that the
live host stayed unchanged; Project Intake therefore MUST re-inspect the host
immediately before Apply. See [project-context invalidation](../project-context-engine.md)
and [editorial-plan workflow](../ai-editorial-workflows.md).
## Stable IDs, revision locks, and digests
### Current identifiers to reuse
- **Host project identity:** use the UXP project GUID/ID returned by the
revisioned project snapshot or project-session surface. Do not substitute a
project name or path.
- **Project-item identity:** use the UXP Project-panel item ID. A display name
may appear in preview copy but is never a mutation selector.
- **Parent identity:** every move records the exact `expectedParentId` from
inspection and must fail if it changed before dispatch.
- **Host snapshot revision:** retain the `project.snapshot` revision from the
same inspection pass as the resolved IDs.
- **Context revisions:** if local project context is used, retain its source,
timeline, and combined context revisions separately. The current context
engine hashes persisted project/media-path identities, and distinguishes a
source change from a timeline-placement change.
The current project snapshot and Project-panel selection resolver are bounded
host reads; the current organization operations use stable project-item and
parent guards. See [UXP capability foundation](../uxp-capability-foundation.md),
[next-ten workflow matrix](../uxp-next-ten-workflows.md), and [project context
engine](../project-context-engine.md).
### Proposed locking algorithm
1. Inspect the explicitly selected project/items and capture `hostProjectId`,
`hostSnapshotRevision`, `selectedItemIds`, and each selected item's current
parent ID.
2. Canonicalize the approved template, the plan, and the selected target list
using deterministic key ordering and UTF-8 JSON. Compute SHA-256 digests
for the template and plan.
3. Bind the preview confirmation to the host project ID, snapshot revision,
template digest, plan digest, capability-attestation ID, operator identity,
and expiry.
4. Immediately before each operation, reacquire the minimal relevant host
state. Reject a changed project ID, stale snapshot/revision, missing
capability, changed parent, changed metadata guard, or changed selection.
5. Use a unique `operationId` for every host mutation. An operation that times
out or loses the bridge after dispatch is **not** repeated automatically;
it must be inspected before a human decides whether to create a new plan.
The digest and attestation binding are proposed. The repository already uses
opaque confirmation tokens and revision-locked previews in its editorial
workflow, while the proposed metadata batch planner calls for an exact project
revision, plan digest, per-item certainty, and no retry of unknown commits.
See [editorial workflow](../ai-editorial-workflows.md) and [metadata batch planner
recommendation](../recommendations/2026-08-18-round-2/38-metadata-batch-planner.md).
## Contract schemas
The following are proposed JSON contract shapes. They are intentionally
separate from existing individual MCP tool schemas. They use synthetic IDs and
contain no native paths, real project names, media names, prompts, transcript
content, or credentials.
### Intake request
```json
{
"schemaVersion": "project-intake-request/v0.1",
"requestId": "pi-20260822-0001",
"template": {
"id": "documentary-intake",
"version": "3.2.0",
"sha256": "sha256:<template-digest>",
"permittedOperations": ["create_bin", "move_item", "set_color", "update_metadata"],
"organizationRules": [
{
"ruleId": "interview",
"destination": { "parentBinId": "bin-root", "name": "Interviews", "colorIndex": 4 },
"match": { "mode": "operator-selected-only" }
}
],
"metadataAllowlist": ["project.description", "xmp.dc:subject"]
},
"scope": {
"hostProjectId": "project-guid-redacted",
"projectViewId": "view-redacted",
"selectedProjectItemIds": ["item-redacted-01", "item-redacted-02"]
},
"policy": {
"id": "facility-default",
"version": "1",
"requireHumanConfirmation": true,
"allowPersistentContext": false
}
}
```
Validation requirements: the template is immutable/versioned; IDs are unique;
the scope contains at least one exact host item ID; every metadata key is
allowlisted; and the caller cannot widen the template's operation set. A rule
using a semantic filename match is outside v0.1. The existing organization plan
requires caller-supplied rules and deliberately does not infer categories from
filenames; this contract keeps the same safety posture. See [local-first
editorial workflows](../ai-editorial-workflows.md).
### Inspection and proposed plan
```json
{
"schemaVersion": "project-intake-plan/v0.1",
"requestId": "pi-20260822-0001",
"state": "preview",
"binding": {
"hostProjectId": "project-guid-redacted",
"hostSnapshotRevision": "uxp-redacted",
"templateSha256": "sha256:<template-digest>",
"capabilityAttestationId": "proposed-attestation-id"
},
"findings": [
{
"findingId": "finding-01",
"kind": "organization",
"status": "actionable",
"targetId": "item-redacted-01",
"evidence": { "expectedParentId": "bin-root" },
"message": "Selected item is approved for the configured destination."
},
{
"findingId": "finding-02",
"kind": "codec",
"status": "unsupported",
"message": "No Project Intake codec-field capability is implemented in this contract version."
}
],
"operations": [
{
"operationId": "pi-op-01",
"type": "move_item",
"target": { "projectItemId": "item-redacted-01", "expectedParentId": "bin-root" },
"destination": { "binId": "bin-interviews" },
"expectedPostcondition": { "parentId": "bin-interviews" },
"authority": "human-confirmed-edit"
}
],
"limitations": [
"Host readback establishes only exposed structural fields.",
"No render, playback, or editorial-quality verification is included."
],
"planSha256": "sha256:<plan-digest>",
"confirmation": { "required": true, "expiresAt": "2026-08-22T20:00:00Z" }
}
```
Every finding MUST say whether it is `pass`, `actionable`, `warning`,
`unsupported`, `not_inspected`, or `blocked`; absence of a finding is never a
pass. Every mutation operation MUST provide an exact stable target, precondition,
expected postcondition, authority class, and recovery instruction. The
`capabilityAttestationId` is proposed: the existing recommendation describes a
nonce-bound, short-lived host capability attestation, but it is not a current
production feature. See [host capability attestation recommendation](../recommendations/2026-08-18-round-2/30-host-capability-attestation.md).
### Receipt
```json
{
"schemaVersion": "project-intake-receipt/v0.1",
"receiptId": "pir-20260822-0001",
"requestId": "pi-20260822-0001",
"endedState": "receipt",
"binding": {
"hostProjectId": "project-guid-redacted",
"hostSnapshotRevision": "uxp-redacted",
"templateSha256": "sha256:<template-digest>",
"planSha256": "sha256:<plan-digest>",
"sourceCommit": "<40-character-source-sha>",
"panelBuild": "<panel-build-hash>"
},
"approval": {
"approvedBy": "operator-pseudonym-or-enterprise-user-id",
"approvedAt": "2026-08-22T19:00:00Z",
"confirmationId": "opaque-confirmation-token"
},
"operations": [
{
"operationId": "pi-op-01",
"type": "move_item",
"result": "structurally_verified",
"verificationBoundary": "project_item_parent_readback",
"evidenceRefs": ["redacted-host-response-ref"],
"recovery": "Use Premiere Undo after visually confirming the item and destination."
}
],
"summary": { "planned": 1, "applied": 1, "structurallyVerified": 1, "unknown": 0 },
"privacy": { "nativePathsIncluded": false, "mediaNamesIncluded": false, "transcriptContentIncluded": false },
"receiptSha256": "sha256:<canonical-receipt-digest>"
}
```
`receiptSha256` is a proposed integrity checksum, not a signature, C2PA claim,
or proof that no later Premiere edit occurred. Receipt storage/transport and
tamper-evident signing require a separate security design. The existing
host-validation runbook requires redacted host facts, fixture checksum, before/
after evidence, structured response, and Undo evidence for a passed mutation;
Project Intake receipts SHOULD reference the same kind of evidence without
embedding sensitive data. See [host-validation runbook](../editorial-workflow-host-validation.md).
## Result certainty
The receipt MUST report a result for the workflow and for every proposed
operation. The following contract normalization is **proposed**; it maps current
command-specific UXP outcomes without weakening their stated boundaries.
| Certainty | Meaning | Retry rule |
| --- | --- | --- |
| `planned` | No mutation was dispatched. | A new plan may be created. |
| `rejected_before_mutation` | A validation, authority, freshness, or capability check stopped the operation before dispatch. | Correct the cause and start a new Inspect/Plan cycle. |
| `committed_unverified` | Premiere accepted/committed the command, but the contract lacks a required readback for the requested effect. | Never retry automatically; inspect the host before a human decides next action. |
| `structurally_verified` | The command-specific host readback matches the expected structural postcondition. | Do not retry; this is not visual, playback, or render proof. |
| `render_verified` | A separately specified exported artifact was verified by the applicable output-file/render procedure. | Not emitted by ordinary v0.1 Project Intake operations. |
| `partial` | At least one operation is structurally verified and a later operation did not complete or is uncertain. | Stop the remaining batch, inspect known changes, then create a new plan. |
| `unknown_mutation` | Dispatch may have reached Premiere, but a timeout/disconnect/invalid response prevents knowing whether it changed state. | Do not retry; require host inspection and a fresh human decision. |
| `failed` | The operation failed before a confirmed postcondition; the receipt must state whether mutation is known absent or unknown. | Follow the classified recovery instruction. |
| `unsupported` / `not_run` | The capability or test evidence is absent. | Do not substitute another backend or a heuristic. |
Current UXP workflows already use command-specific readback and, for some
operations, `committed_unverified`; the current organization route reports
verified actions as `partial` if a later action fails and never silently rolls
back or retries an unknown commit. Current `verified` is structured host
readback, not licensed-host visual/render validation. See [third-wave workflow
matrix](../third-wave-uxp-workflows.md), [editorial workflows](../ai-editorial-workflows.md),
and [transaction deadline/readback recommendation](../recommendations/2026-08-18-round-2/32-transaction-deadline-readback.md).
## Failure taxonomy and recovery
| Code | Classification | Required receipt data and recovery |
| --- | --- | --- |
| `PI_CONNECTION_UNAVAILABLE` | `rejected_before_mutation` | Backend requested, connection-check result, and instruction to reconnect; no fallback mutation. |
| `PI_CAPABILITY_MISSING` | `unsupported` | Required command and advertised capability set; leave the check unresolved. |
| `PI_PROJECT_IDENTITY_CHANGED` | `rejected_before_mutation` | Expected/current redacted project IDs; restart Inspect. |
| `PI_REVISION_STALE` | `rejected_before_mutation` | Expected/current revision fingerprints; restart Inspect and Preview. |
| `PI_TEMPLATE_OR_PLAN_MISMATCH` | `rejected_before_mutation` | Template/plan digest identifiers only; obtain a new approval. |
| `PI_CONFIRMATION_INVALID` | `rejected_before_mutation` | Non-sensitive reason: missing, expired, rejected, or wrong approver; do not dispatch. |
| `PI_TARGET_AMBIGUOUS` | `rejected_before_mutation` | Candidate stable-ID count and rule ID; require the operator to reselect exact items. |
| `PI_GUARD_FAILED` | `rejected_before_mutation` | Target ID and expected/current parent or field fingerprint; re-inspect instead of forcing a move. |
| `PI_POLICY_DENIED` | `rejected_before_mutation` | Policy version and denied operation class; administrator/supervisor must change policy explicitly. |
| `PI_WORKSPACE_DENIED` | `rejected_before_mutation` | Workspace access mode only; ordinary v0.1 scope should not need a path workaround. |
| `PI_HOST_MODAL_OR_TIMEOUT` | `unknown_mutation` if dispatched, otherwise `rejected_before_mutation` | Last known phase and operation ID; inspect Premiere before retry. |
| `PI_INVALID_HOST_READBACK` | `unknown_mutation` | Raw response stays redacted; stop the batch and inspect the stated target. |
| `PI_PARTIAL_APPLY` | `partial` | Per-operation certainty, already changed IDs, remaining operations, and explicit Undo/manual recovery guidance. |
| `PI_PRIVACY_VIOLATION` | `rejected_before_mutation` | Field class rejected, not its value; redact and create a new request. |
The implementation MUST preserve the last known state if Apply begins: preflight,
dispatch, host return, and readback are distinct phases. It MUST NOT report a
successful rollback merely because a later operation failed. This follows the
current organization-plan and transaction/readback boundaries. See [editorial
workflows](../ai-editorial-workflows.md) and [transaction deadline/readback
recommendation](../recommendations/2026-08-18-round-2/32-transaction-deadline-readback.md).
## Privacy, data handling, and audit rules
### Contract rules (proposed)
1. Project Intake MUST be local-first by default. It MUST enumerate any network
egress before a facility enables it and MUST not transmit footage, native
paths, media names, transcript content, metadata values, prompts, or receipt
bodies to telemetry or a model provider without a separately approved data
path and retention policy.
2. Receipts MUST use stable IDs or one-way/deliberately redacted identifiers;
they MUST exclude native paths, media names, transcript content, raw metadata
values, credentials, persistent workspace tokens, and full raw host events.
3. Facility templates MUST be versioned and may contain rule IDs, field keys,
and policy references. They MUST NOT contain secrets, production media paths,
customer content, or hidden broad filesystem roots.
4. Persistent state MUST be opt-in and deletable. The workflow MUST surface
where it is stored, retention duration, and the clear action.
5. The authoritative receipt is an operation record, not a training-data grant,
provenance assertion, copyright determination, or productivity claim.
### Current constraints to honor
The current project-context engine is opt-in and local; it persists project
names, hashed project/media-path identities, bounded timeline metadata, and
explicit enrichments, while not persisting native paths. It also discards
enrichment keys resembling paths, passwords, tokens, secrets, or API keys.
Project Intake MUST obtain explicit operator consent before using that store and
MUST clear it when the chosen retention policy requires it. See [project context
storage rules](../project-context-engine.md).
The current UXP workspace access model returns neither the native workspace root
nor persistent token over MCP, and current workflow checkpoints forbid secrets,
paths, transcripts, and media names because persistent values may sync with
cloud projects. Project Intake MUST not bypass either boundary. See [README UXP
workspace policy](../../README.md) and [third-wave checkpoints](../third-wave-uxp-workflows.md).
## Host validation matrix
All cases below are **proposed Project Intake validation cases** and start as
`not_run`. Unit, contract, lint, and mock-bridge tests may validate schemas and
failure handling, but cannot mark a case licensed-host verified. Use a copied,
disposable project with generated, non-sensitive fixture media; retain redacted
responses, before/after Project-panel evidence, and Undo evidence. This extends
the existing [editorial host-validation runbook](../editorial-workflow-host-validation.md).
| ID | Coverage | Procedure | Required pass evidence | Boundary retained |
| --- | --- | --- | --- | --- |
| `PI-PLAN-001` | Each supported MCP client path on Windows and macOS | Inspect a fixture selection; create and preview a plan with one unsupported check. | No mutation; IDs/revision/digest present; unsupported check remains unresolved. | Does not prove host mutation. |
| `PI-ORG-001` | Each claimed Premiere/UXP/OS combination | Create or resolve one bin, move one selected item, apply one color rule. | Exact stable IDs/parent/color readback, before/after Project-panel captures, and Undo restores fixture. | Structural UI state only; no editorial-quality claim. |
| `PI-ORG-002` | Same as `PI-ORG-001` | Change the source parent after Preview. | Guard rejects before move; any earlier verified create is recorded as partial and manually undone. | No atomic rollback claim. |
| `PI-META-001` | Each claimed Premiere/UXP/OS combination | Read and update one allowlisted metadata field, including Unicode and no-op cases. | Requested-field readback and Undo evidence. | Field readback does not validate an external asset-management system. |
| `PI-MEDIA-001` | Each claimed Premiere/UXP/OS combination | Inspect offline/proxy health for 1, 64, and over-limit selections. | Bounded per-item receipt; no path disclosure without explicit approved request. | Does not establish real-media availability beyond exposed host state. |
| `PI-PRODUCTION-001` | Project and Production fixture where the host advertises it | Run storage/ingest preflight without mutation. | Redacted preflight response and no project-state change. | Does not validate Production configuration mutation. |
| `PI-FAULT-001` | Each claimed Premiere/UXP/OS combination | Disconnect/timeout after a dispatched fixture mutation; repeat with invalid readback. | `unknown_mutation`, no automatic retry, human inspection decision recorded. | Does not prove the prior command did or did not mutate. |
| `PI-PRIVACY-001` | Windows and macOS | Attempt to place path, token-like, transcript, and media-name fields in template, receipt, and checkpoint inputs. | Rejection/redaction before persistence or output. | Does not prove third-party provider retention policy. |
Each report MUST include source commit, panel build hash, Premiere version, OS
version, MCP client, fixture revision/checksum, case status, and evidence
references. A case is `passed`, `failed`, `unsupported`, or `not_run`; a
passing schema validator or an MCP response labeled `verified` is insufficient
without human review of the exact host and post-state evidence. The repository
now provides a separate, versioned
`npm run validate:project-intake-host-report -- path/to/redacted-report.json`
contract for this preview-only workflow. It accepts only the defined Project
Intake cases, requires the documented non-mutation postconditions, and rejects
project data from the shared evidence index. See the
[Project Intake host-validation runbook](../project-intake-host-validation.md).
## Acceptance gates
These are proposed promotion gates. They are not met merely because this
document exists or because current automated tests pass.
### Contract and implementation gate
- A versioned JSON schema validates request, plan, confirmation, receipt, and
each failure/result state.
- Tests prove no mutation is reachable from Inspect, Plan, Preview, Confirm,
Verify, or Receipt.
- Tests prove stale project/revision/template/plan/confirmation/parent guards
fail before dispatch.
- Tests prove duplicate or ambiguous targets, unallowlisted metadata, and
forbidden operations fail before dispatch.
- Tests prove a UXP failure never falls back to CEP/QE and an unknown commit is
never automatically retried.
- Tests prove receipts redact forbidden fields and capture per-item partial
completion with last known phase.
- Documentation lists every required host command, version/capability gate,
postcondition, certainty boundary, and recovery instruction.
### Licensed-host pilot gate
- At least 100 documented, real-host Project Intake runs across every
Premiere/OS/client combination claimed for the workflow, using the matrix
above and the exact source/panel builds being considered.
- Zero wrong-project or wrong-project-item mutations in those runs.
- At least 99% of attempted supported operations reach their specified
structural postcondition, with every exception classified and recoverable.
- Every mutation has an attributable human confirmation, exact target IDs,
before/after evidence, and Undo/manual-recovery evidence appropriate to the
operation.
- No failed or disconnected apply is labeled successful without the required
readback; no automatic retry follows an uncertain dispatch.
- At least two design-partner teams repeat the workflow after supervised use.
Any time-saving claim is based on recorded baseline and assisted durations,
sample size, and rework—not an estimate.
### Security and release gate
- The deployment mode, model routing, network egress, identity/role behavior,
audit retention/deletion, update channel, and emergency revocation path are
documented and accepted by the pilot facility.
- The signed build and source/panel hashes in every receipt are reproducible.
- A privacy review confirms that templates, context, telemetry, receipts, and
host reports follow the rules in this contract.
- Marketing says "proposed," "pilot," "licensed-host verified for listed
combinations," or "unsupported" as applicable; it never extrapolates a
successful fixture run to all productions.
Until every applicable gate is met, Project Intake is an implementation/pilot
workflow only. Current automated coverage and command-specific UXP readback are
valuable engineering evidence, but remain separate from licensed-host and
rendered-output evidence. See [verification matrix](../ai-editorial-workflows.md)
and [reproducible live-host lab recommendation](../recommendations/2026-08-18/17-live-host-lab.md).
## Implementation checklist
1. Add the proposed schemas and a canonical-digest implementation without
changing existing individual tool semantics.
2. Add a read-only `inspect` and `plan` path first; report unavailable checks
explicitly rather than adding heuristics.
3. Reuse the existing reviewed UXP organization route for a narrow first apply
adapter; do not expose direct raw bin operations as the guided workflow.
4. Add metadata only after a separate exact field allowlist, readback mapping,
and host tests exist.
5. Add confirmation/receipt persistence behind an explicit privacy and identity
design; do not put receipt bodies in cloud-synced workflow checkpoints.
6. Run the host matrix and preserve redacted evidence before widening the
supported-version statement.
code/docs/industry/security-and-design-partner-pilot.md
Executable
+502
View File
@@ -0,0 +1,502 @@
# Security and design-partner pilot for professional post-production
## Purpose and status
This document defines a proposed 60-day design-partner pilot for a narrowly
scoped **Project Intake Assistant**. It is intended for Premiere-based post
teams that want to test reviewed project inspection and organization workflows
without delegating creative authorship or uncontrolled access to production
media.
The pilot is a product-discovery and evidence-gathering activity. It is **not**
a security certification, legal advice, a TPN assessment, a claim of
production readiness, or permission to process a customer's media. A facility
must approve its own data, labor, clearance, security, and retention policies
before participating.
Terms in this document are deliberately distinct:
- **Current repository behavior** is grounded in linked implementation and
documentation evidence.
- **Pilot requirement** is a condition for participating in the proposed
program.
- **Proposal** is a future product or operating control that is not represented
as implemented until it has code, tests, and licensed-host evidence.
## Evidence basis and present boundaries
The repository documents a recommended local `stdio` deployment in which the
MCP client, server, Premiere connector, and host run on the same computer. The
CEP bridge uses a private per-user temporary directory; the optional UXP bridge
listens only on `127.0.0.1` and authenticates its WebSocket connection. See the
[local setup and security guidance](../../README.md#security) and the
[UXP bridge transport contract](../../uxp-plugin/README.md#mcp-side-transport).
The current project-context store is local and opt-in. It persists bounded
metadata and hashed project/media-path identities, not native project or media
paths, but it can persist explicit enrichment content when an MCP client asks
it to do so. Its storage boundary does not make an AI client or model provider
private. See the [project-context engine](../project-context-engine.md) and the
[context-retention proposal](../recommendations/2026-08-18-round-2/36-context-retention-policy.md).
The repository also supports a network-reachable HTTP transport, but it binds
to `0.0.0.0`, requires bearer authentication in production, and is not a safe
default for a shared post facility without identity-aware edge controls. It is
therefore excluded from the pilot baseline. The existing UXP manifest declares
`network.domains: "all"` for Premiere compatibility, even though the panel CSP
and its workspace validator restrict the configured bridge to loopback URLs.
That broad declared permission is a material installation-review issue, not a
claim that the current panel can be accepted by every facility policy.
Existing code and documentation distinguish host responses and structural
readback from playback or rendered-output proof. Automated checks do not prove
that a licensed Premiere host created, displayed, saved, or undid an item. See
the [licensed-host validation runbook](../editorial-workflow-host-validation.md)
and the [sequence-sandbox proposal](../recommendations/2026-08-18-round-2/39-sequence-sandbox-verification.md).
## Pilot scope
The initial pilot is limited to this workflow:
1. Inspect an explicitly selected project and selected incoming media.
2. Compare it with a facility-approved intake template.
3. Produce a read-only issue report and an exact proposed organization plan.
4. Let an authorized human review, edit, reject, or approve the plan.
5. Apply only supported, explicitly approved organization actions.
6. Reinspect the affected targets and create a content-free operation receipt.
The following are out of scope for all pilot stages unless a later, separately
approved protocol says otherwise:
- autonomous editorial or story decisions;
- background monitoring of projects or storage;
- arbitrary ExtendScript or expression execution;
- generative video, audio, voice, face, performance, or final-production
media;
- unreviewed external review, asset-management, delivery, or transcription
integrations;
- automated source-to-sequence transcript cutting, rendered-output claims, and
production turnover claims; and
- shared remote MCP control planes, shared bearer tokens, or public endpoints.
## Local-first pilot topology
The proposed baseline keeps control and operational evidence inside the
facility-managed workstation or network boundary. It does not make claims about
what an independently chosen AI client, operating system, Adobe service, or
network appliance does with data.
```text
Facility-controlled workstation
Approved MCP client
| stdio only
v
Premiere Pro MCP server --------> local project-context store (opt-in)
| |
| private local IPC | facility retention policy
v v
CEP connector / authenticated UXP loopback bridge
|
v
Licensed Premiere Pro and operator-selected workspace
No pilot-default Internet egress from the MCP server or connector.
No remote HTTP/SSE transport. No vendor analytics key. No external model call
from the workflow pack.
```
### Pilot requirements
- Run the MCP server locally over `stdio`; keep the MCP client, server,
connector, and Premiere host on the same facility-managed machine.
- Do not start `http-server`, deploy the pilot workflow to Fly.io, configure
`MCP_AUTH_TOKEN`, or expose a bridge directory through a sync agent, proxy,
or VPN as part of the pilot.
- Use a dedicated pilot configuration with `POSTHOG_API_KEY` unset. The pilot
administrator must record that setting in the installation evidence.
- Use only a facility-approved MCP client and model-routing configuration. The
client must be able to keep prompts, tool arguments, transcript text, media
names, project names, and local paths inside the facility's approved data
boundary. If that cannot be shown, use synthetic fixtures only.
- Review the exact connector package hash, server package version, and UXP
manifest before installation. A facility that cannot accept the current
broad UXP network declaration must not enable the UXP route in the pilot.
- Grant the UXP panel one operator-selected workspace only. Treat workspace
containment as a bridge policy rather than an operating-system sandbox, and
do not use a workspace that includes unrelated productions.
- Default to read-only inspection. Run application only through the guarded
organization path after the named approver reviews an unstale plan.
## Egress inventory
This inventory is deliberately conservative. It records known paths in the
repository and the pilot disposition; it is not a substitute for a facility's
endpoint monitoring and package review.
| Surface | Current repository behavior | Pilot disposition | Data permitted to leave the workstation |
| --- | --- | --- | --- |
| MCP client to local server | Local `stdio` is the recommended path. The repository does not control the client or model provider selected by a facility. | Allowed only after the facility approves the specific client and model route. | Only what the approved client is authorized to process; this document makes no assumption that the client is private. |
| Server to CEP connector | Local file-based IPC in a private per-user bridge directory. | Allowed. Keep both processes on the same workstation and do not sync the directory. | None off-workstation. |
| Server to UXP panel | Authenticated WebSocket on `127.0.0.1`; panel CSP and runtime URL validation allow loopback URLs. | Allowed only after manifest review and an accepted workspace permission. | None off-workstation. |
| Project-context store | Local application-data store; opt-in capture; paths are hashed before persistence. Explicit enrichments may contain user-provided text. | Allowed only in a customer-controlled encrypted-at-rest location with an approved retention setting. | None by the server itself. |
| PostHog telemetry | Disabled unless `POSTHOG_API_KEY` is configured. When enabled, code records bounded operational events and disables person profiles. | Prohibited. Leave the key unset and verify no telemetry host is configured. | None. |
| HTTP/SSE MCP transport | Optional, network-reachable server route with bearer authentication and rate limits. | Prohibited. Do not start it or route it through a tunnel, proxy, sync agent, or remote host. | None. |
| Adobe cloud features | The repository exposes capability reporting and, in limited cases, observation after an editor uses a Premiere feature. It does not make current MCP calls to initiate Adobe generative features. | Excluded from the workflow. Any Adobe network feature remains an independent customer/Adobe relationship. | None through this pilot workflow. |
| C2PA soft-binding inspection | A read-only, separately consented external-inspection lab is proposed, not a stable pilot action. | Prohibited. | None. |
Before each pilot stage, the facility administrator records the package hashes,
environment-variable names and whether set, enabled transports, the selected
MCP client, and observed outbound destinations. The record must contain no
tokens, prompts, local paths, project names, or media names.
## Telemetry and content-handling rules
The existing optional PostHog implementation documents a bounded event contract:
operational events may include a method, tool name, outcome, status code, and
duration; it excludes authentication tokens, IP addresses, MCP arguments,
project paths, media names, tool results, and person profiles. That is useful
implementation evidence, but the design-partner baseline is stricter: no vendor
telemetry is enabled.
The pilot must not collect, transmit, or place in shared pilot reports:
- video, audio, stills, proxies, exports, render frames, checksums that can be
used to retrieve content, or raw file contents;
- project, Production, sequence, bin, clip, media, storage-root, user, client,
production, or facility names;
- native paths, workspace tokens, bridge tokens, credentials, IP addresses,
device identifiers, browser storage, or authentication headers;
- prompts, tool arguments, tool results, editor notes, raw transcript text,
shot descriptions, dialogue, captions, review notes, or metadata values;
- face, voice, performance, biometric, likeness, talent, clearance, or labor
information; and
- persistent cross-facility identifiers or behavioral profiles.
**Proposal — content-free pilot measurements.** Use locally generated,
rotating participant and project aliases; retain the alias mapping only inside
the facility. Share aggregates such as stage, host version, action class,
result certainty, elapsed duration band, and issue category. A shared report
must redact or omit any field that could identify a production or reconstruct a
request.
## Roles and approvals
The pilot does not give an AI client independent authority. One person may hold
multiple roles only if the facility explicitly accepts that separation-of-duty
risk.
| Role | Responsibilities | May approve |
| --- | --- | --- |
| Facility administrator | Installs approved packages, confirms local-only configuration, controls access and revocation, and keeps the egress record. | Enrollment, configuration changes, and any exception to the local-first baseline. |
| Workflow owner / post supervisor | Converts an existing intake SOP into a versioned pilot template, defines expected outputs, and reviews pilot outcomes. | Template changes and promotion between pilot stages. |
| Assistant editor | Selects the intended project/media, reviews issues and proposed actions, and performs or witnesses the workflow. | Read-only runs and submission of a plan for approval. |
| Editor or designated post approver | Retains editorial judgment and confirms that a specific plan may modify the identified project targets. | Each mutating plan; a separate confirmation for non-undoable action. |
| Security/privacy reviewer | Reviews model route, telemetry state, permissions, retention, and incident evidence. | Any data-flow exception, use of cleared active-project media, and case-study release. |
| Pilot evidence reviewer | Checks redaction, host facts, post-state evidence, and claim wording. | A result may be counted toward a published case study. |
### Approval contract for a mutation
For each application attempt, the system and pilot record must present:
1. the project and target identities as aliases plus a facility-local lookup;
2. the captured project/context revision and plan digest;
3. the exact proposed creates, moves, labels, or metadata actions;
4. action-level undoability and known verification boundary;
5. the approving human, time, and expiration; and
6. the post-operation readback and result certainty.
The pilot must reject a stale plan, ambiguous target, expired approval, changed
project, unavailable host capability, missing bridge authentication, or unknown
workspace authority. It must never automatically retry a mutation after an
uncertain commit. A partial result is a visible outcome, not a successful batch.
**Proposal — two-person gate.** Require both the assistant editor and the
designated post approver for a plan that crosses projects, writes outside the
expected intake bins, affects more than the facility-defined batch limit, or
contains a non-undoable action. No role may approve an `unsafe-script` action
in this pilot because that authority remains out of scope.
## Generative-media separation
Generative operations require their own data, rights, talent, labor, clearance,
and provenance review. They are not an extension of ordinary project
organization.
The design-partner pilot therefore:
- does not invoke or ask an AI service to synthesize video, stills, dialogue,
music, sound effects, voice, face, performance, captions, or metadata;
- does not send source material, transcripts, likenesses, or performance data
to a generative provider;
- does not claim that a Premiere-generated item is cleared, human-authored,
licensed, factual, or authentic;
- may inspect an already-existing item only as an ordinary project/timeline
item, without treating inspection as evidence of provenance; and
- keeps any future generative experiment in a separate feature flag, consent
record, approved data route, rights/clearance review, and visibly labeled
output path.
The current repository similarly reports generative features as user-assisted
or unavailable rather than presenting a stable MCP generation operation. The
proposed C2PA inspection lab is read-only, disabled by default, and explicitly
does not make an authenticity verdict. See
[advanced feature boundaries](../../README.md#collaboration-and-ai-feature-boundaries)
and the [C2PA inspection proposal](../recommendations/2026-08-19-round-3/48-c2pa-inspection-lab.md).
## Audit, receipts, and retention
The immediate audit record is an operational receipt, not a surveillance log
and not a claim that a rendered result is correct. Existing guidance already
distinguishes bounded, redacted event receipts and licensed-host evidence from
visual or render verification.
**Proposal — minimum receipt fields.** Store the following in a facility-owned
location with access limited to the pilot roles:
```json
{
"receiptVersion": "1",
"pilotRunAlias": "facility-local alias",
"workflowPackVersion": "version or source commit",
"host": {
"os": "Windows or macOS",
"premiereVersion": "observed version",
"connectorBuild": "build hash",
"backend": "cep or uxp"
},
"plan": {
"digest": "hash of the reviewed plan",
"capturedRevision": "facility-local revision alias",
"actionCounts": { "inspect": 0, "create": 0, "move": 0, "label": 0 }
},
"approval": { "approverRole": "post_approver", "expiresAt": "timestamp" },
"result": {
"state": "planned | rejected_before_mutation | committed_unverified | structurally_verified | render_verified",
"perAction": "content-free statuses only",
"undoChecked": false
},
"evidence": ["facility-controlled redacted evidence reference"]
}
```
No receipt may include raw targets, names, paths, prompt content, transcript
text, token values, or media-derived content. `render_verified` must remain
unused for Project Intake unless a documented render-specific procedure is
separately run; a successful API response or property readback is not enough.
**Proposal — retention rule.** Default receipt retention to 30 days for the
pilot, with a facility-selected shorter period where required. Keep only
aggregated, fully de-identified measurement results after deletion. Deletion
must remove primary and derived local pilot records and produce a content-free
deletion receipt. Do not retain a transcript or enrichment merely because a
receipt exists. The 30-day interval is an operational starting point, not a
legal retention recommendation.
## TPN-readiness framing
TPN readiness is a useful way to organize a facility-security conversation, but
this repository and pilot do **not** claim TPN membership, assessment, approval,
certification, endorsement, or compliance.
**Proposal — readiness evidence pack.** Before a facility considers a formal
third-party assessment, map the pilot's evidence to questions a content-security
review commonly asks:
- asset and data-flow inventory, including each outbound destination and the
proof that the default pilot has none;
- package origin, build hash, signing/distribution method, dependency inventory,
update owner, and revocation/rollback procedure;
- individual identities, least privilege, approval records, secret handling,
workstation access controls, and offboarding;
- network architecture, firewall/egress rules, remote-support policy, logging
boundaries, incident escalation, and evidence preservation;
- encryption, facility-selected storage and backup policy, retention/deletion,
vendor/model review, and subcontractor exclusions; and
- security test results, licensed-host validation reports, known limitations,
and remediation ownership.
This pack should identify gaps plainly. A completed checklist is readiness
evidence for a future review, not a substitute for the requirements or decision
of a studio, facility, insurer, customer, or TPN assessor.
## Design-partner recruitment
Recruit three to five Premiere-based teams. The first cohort should favor teams
whose intake work is frequent, documented, and structurally verifiable:
- documentary, unscripted, interview-heavy, trailer/promotional, branded, or
independent-feature post teams;
- approximately three to twenty editorial users, with at least one working
assistant editor and one empowered post supervisor;
- a licensed Premiere installation that the facility may use for controlled
fixture and duplicate-project tests on a supported operating system;
- a real intake SOP containing naming, bin, label, metadata, proxy, and
exception rules that can be expressed without story judgment;
- a technical/security contact who can approve the client/model route and
local-only setup; and
- willingness to measure a manual baseline, run supervised sessions, report
failures, and decline to use the workflow when its evidence is insufficient.
Exclude a candidate from the first cohort if it requires public remote access,
cannot disable telemetry, needs generated media, expects autonomous editing,
cannot use duplicate or cleared project material for early stages, or cannot
assign a named approver.
## Proposed 60-day pilot stages
| Stage | Days | Allowed material and actions | Required exit evidence |
| --- | ---: | --- | --- |
| 0. Enrollment and threat review | 1–7 | No project actions. Review SOP, model route, installation package, permissions, topology, retention, roles, and stop procedure. | Signed facility-local pilot charter; egress inventory; template v1; named roles; baseline measurement plan. |
| 1. Fixture rehearsal | 8–21 | Generated or non-sensitive fixture media only. Read-only reports first, then one-action organization tests in disposable copied projects. | At least ten runs per team; redacted before/after/Undo evidence for each mutation; no unapproved egress. |
| 2. Duplicate-project validation | 22–42 | Completed, cleared, or duplicate projects approved by the facility. Apply only approved bin, move, label, and metadata operations. | At least twenty additional runs per team; stale-plan/ambiguous-target/host-disconnect drills; per-action structural readback and recovery evidence. |
| 3. Supervised operational trial | 43–60 | Facility-approved active-project intake only if the security reviewer authorizes it. Human approval remains mandatory; no generative or remote integration. | Repeated voluntary use, baseline comparison, unresolved-risk register, and an evidence-reviewed end-of-pilot decision. |
The transition to a later stage requires the workflow owner and security/privacy
reviewer to accept the prior-stage evidence. Failure to meet a target does not
justify changing the evidence definition or silently broadening a claim.
## Metrics and decision gates
Measure both benefit and safety. All measurements must use facility-local
aliases and time bands or aggregates; do not export content-bearing logs.
| Category | Metric | Interpretation boundary |
| --- | --- | --- |
| Reliability | Completed runs / attempted runs; structurally verified actions / approved actions; partial/unknown results | Counts host and workflow outcomes, not editorial correctness or render quality. |
| Targeting safety | Wrong-project, wrong-sequence, wrong-item, stale-plan, and approval-bypass events | Any wrong-target mutation is a stop condition, not an acceptable error rate. |
| Recoverability | Undo/recovery success, time to identify uncertainty, time to restore fixture state | Recovery in a fixture does not prove recovery for every production condition. |
| Human control | Plan edit/rejection rate, approval rate, approver identity coverage, and unapproved-action count | A high rejection rate may reveal useful guardrails or a poor template; it is not automatically failure. |
| Workflow value | Median manual versus assisted intake time, manual correction time, and repeat voluntary use | Report sample size, task definition, material type, and confidence limits; do not generalize to all editing. |
| Security/privacy | Observed outbound destinations, telemetry-disabled checks, permission exceptions, receipt-redaction defects | A passing check verifies the inspected setup only; it is not a facility-wide security assessment. |
| Usability | Install-to-first-verified-run time, operator confidence, and support interventions | Self-reported confidence is not proof of host reliability. |
**Proposed promotion gate.** Do not present Project Intake as production-ready
until at least 100 licensed-host runs across every claimed host configuration
show no wrong-project, wrong-sequence, or wrong-media mutation; every mutation
has attributable approval; uncertain commits were not retried; and structural
readback, recovery, and egress records were independently reviewed. This is a
future gate, not a statement that the current repository has passed it.
## Stop conditions and incident handling
Immediately pause the affected workflow and prohibit further application in the
following situations:
- a mutation targets the wrong project, Production, sequence, item, bin, or
workspace;
- a plan is applied without a valid named approval, or a stale/digest-mismatched
plan is accepted;
- a mutation returns an uncertain, partial, conflicting, or unverifiable result
that the operator cannot safely inspect and recover;
- any prompt, transcript, tool argument/result, path, token, media name, or
customer content appears in vendor telemetry, a shared report, or an
unapproved outbound destination;
- the configured MCP client or model route changes without security review;
- a bridge token, package, manifest permission, workspace authority, endpoint,
or project-storage root changes unexpectedly;
- an attempted feature crosses into generative, remote, arbitrary-script, or
external-integration scope; or
- a participant reports a labor, privacy, clearance, security, or customer
policy conflict.
The facility administrator first disconnects the bridge and preserves only
content-free diagnostic facts. The workflow owner then determines whether the
project needs manual inspection, Undo/recovery, or escalation under the
facility's incident process. The pilot evidence reviewer records the condition
as `failed`, `partial`, `unknown`, or `not_run`; it must never be reclassified
as successful merely because the host later appears normal. Resume requires a
documented root-cause review, updated template or control, a fixture rehearsal,
and fresh approver authorization.
## Evidence template
Use one redacted record per run. Keep screenshots, bridge responses, project
copies, and alias mappings inside the facility; references below are opaque,
facility-controlled IDs rather than files to be shared externally.
```yaml
pilot_run_alias: P-017
date_bucket: 2026-W35
stage: fixture_rehearsal
workflow: project_intake_v1
workflow_pack_version: "commit-or-signed-package-hash"
host:
os: Windows
premiere_version: "facility-recorded"
connector_build: "hash"
backend: uxp
configuration:
transport: stdio
http_server_started: false
telemetry_key_configured: false
uxp_manifest_reviewed: true
approved_workspace_confirmed: true
outbound_destinations_observed: []
plan:
project_alias: PRJ-LOCAL-4
revision_alias: REV-LOCAL-9
digest: "sha256-or-equivalent"
actions: { inspect: 12, create: 1, move: 4, label: 4 }
approval:
assistant_editor_present: true
post_approver_present: true
approval_expires_before: "facility-local timestamp"
result:
status: structurally_verified
per_action_summary: { succeeded: 9, rejected_before_mutation: 0, partial: 0, unknown: 0 }
undo_checked: true
render_verified: false
evidence_references:
- FACILITY-ONLY-BEFORE-AFTER-001
- FACILITY-ONLY-UNDO-001
issues:
- none
review:
redaction_checked: true
eligible_for_aggregate_metrics: true
```
This template is intentionally compatible with, but does not replace, the
repository's [licensed-host report shape](../editorial-workflow-host-validation.md#report-shape).
The host report remains necessary before a claim crosses from automated
contracts to a licensed-host capability claim.
## Case-study claim gates
No public case study, sales claim, or partner quote may be created from a pilot
until all of the following are true:
1. The facility has given explicit written approval for the specific identity,
quote, logo, workflow description, and data that may be published.
2. The security/privacy reviewer confirms that the exported evidence contains
no customer content, identifiers, prompts, transcript text, paths, or hidden
telemetry.
3. The evidence reviewer confirms the exact host versions, package/build hashes,
run count, workflow stage, outcome classifications, and failure count.
4. The reported time comparison defines the baseline, task, measurement method,
sample size, material class, manual-correction treatment, and date range.
5. At least two teams have voluntarily repeated the workflow after supervised
sessions. A single successful demonstration is not an adoption claim.
6. Any result stated as verified is limited to the evidence actually collected:
planning, structural project readback, Undo/recovery, or separately measured
render verification.
7. The copy says what happened in the measured pilot, for example, “Across
_N_ supervised intake runs at participating teams, median measured intake
time changed from _X_ to _Y_ for the defined workflow,” rather than claiming
general editing speed, autonomous editing, security certification, or
universal Premiere compatibility.
Published material must retain a limitations note: pilot outcomes do not prove
creative quality, delivery correctness, rights clearance, model privacy outside
the approved route, or compatibility with untested Premiere/client/operating
system combinations.
## Next decision
Before recruiting a design partner, implement or formally accept the proposed
configuration attestation, content-free receipts, retention/deletion controls,
plan digest/expiry, per-action result certainty, and stop/resume workflow. Then
run the existing licensed-host validation procedure with non-sensitive fixtures
on every configuration that the pilot intends to name. Until then, this document
is a proposed control plan, not evidence that the controls are in production.