Skip to content

Hypothesis: PAL Prompt Layer and PAL Conformance Assessment Layer

An Experimental Translation and Diagnostic Structure for PAL-Supported Image Generation

Status: Promising experimental hypothesis — accepted for documentation and validation testing, but not yet adopted as a finalized PAL specification.

Opening Definition

The PAL Intent-to-Execution and Conformance Architecture is a proposed operational structure for translating approved PAL source definitions into inspectable model-facing execution conditions, generating candidate outputs, and diagnosing their conformance against those approved definitions. Rejection, recovery, and adoption remain within the CIP-governed process, with final adoption authority retained by the human operator.

Scope Note

This document proposes an experimental extension to PAL-supported workflows. It is not a normative PAL specification, and it does not redefine C, A, A′, B′, CIP, or PAL.

Fixed terminology preserved in this document:

  • C is model-side or execution-structure mediation that transforms A into A′.
  • The current fixed reconstruction model is:
A → (A + C) → A′ → B′
  • When describing mismatch or drift:
A → (A + C) → A′ → B′ ≠ B

Definitions and boundaries:

  • C is not only error, noise, or creative contribution.
  • The PAL Prompt Layer is not equivalent to C as a whole.
  • The PAL Prompt Layer may participate in execution-structure mediation and may therefore become part of C.
  • CIP does not directly control C or A′.
  • CIP governs validation, rejection, purge, re-binding, re-convergence, and adoption.
  • PAL supports continuity, persistence, and anchor availability.
  • The human operator retains final adoption authority.
  • Conformance outputs are diagnostic evidence only.
  • PAL does not directly govern adoption.

This document does not describe PAL as directly governing adoption. It does not describe a conformance output as replacing human validation. It does not describe the PAL Prompt Layer as controlling or eliminating C.

Core Hypothesis

PAL source definitions may be correct — accurately describing the approved character, costume, background, and sequence conditions — while still producing unstable outputs when the pre-existing path from those definitions to a model-facing prompt is not explicitly structured into the PAL Prompt Layer blocks.

In other words: PAL may correctly define A, but the path from A to a task-specific model-facing prompt is itself a transformation step. If that step is undocumented or insufficiently inspectable, it may introduce drift before generation begins.

This document proposes that PAL-supported workflows may benefit from an explicit translation layer — the PAL Prompt Layer — positioned between PAL source modules and the generative model, and an explicit diagnostic layer — the PAL Conformance Assessment Layer — positioned between the generated candidate and the CIP-governed adoption process.

Proposed Structure

PAL Source Modules
  ├─ Character PAL
  ├─ Costume PAL
  ├─ Background PAL
  └─ Sequence PAL
          ↓
PAL Prompt Layer
  ├─ Identity Block
  ├─ Scene Variable Block
  └─ Anti-drift Block
          ↓
Initial Execution Package
          ↓
Pre-Execution Conformance Check
          ↓
Human-Governed Review Decision
  ├─ PROCEED → Final Execution Package
  ├─ REVISE  → Revision → Second Human-Governed Review
  │                         ├─ PROCEED → Final Execution Package
  │                         ├─ REVISE  → Further action under the pre-registered review policy
  │                         └─ STOP    → No Generation; Record Outcome
  └─ STOP    → No Generation; Record Outcome

Only the PROCEED branches continue below:
Final Execution Package
          ↓
Generation
          ↓
Generated Candidate
          ↓
PAL Conformance Assessment Layer
          ↓
CIP-Governed Validation, Recovery, and Adoption Process
          └─ Human Operator Retains Final Adoption Authority

Only an execution unit receiving a human-recorded PROCEED decision advances to the Final Execution Package and generation. REVISE and STOP do not independently advance to generation.

The Initial Execution Package and Final Execution Package are review states of the same task-specific artifact compiled through the PAL Prompt Layer. They are not separate globally defined concepts or additional architectural layers. The Initial Execution Package is preserved before review. When no revision is required, the initial and final states are identical. The Final Execution Package is the reviewed package authorized by the human operator for generation after a PROCEED decision. Neither state is identical to A′.

PAL Source Modules

PAL Source Modules are the approved source-level definitions for identity, continuity, permitted variation, and drift boundaries. They function as the operator-approved authoritative reference for the current workflow — the current approved source of truth for continuity evaluation.

Do not treat an unvalidated or merely earlier definition as authoritative. Only definitions that have passed the applicable human validation and approval process and have been accepted into the PAL library constitute approved PAL source definitions. For character-anchor materials, this may include the applicable CIP identity gates.

PAL Prompt Layer

The PAL Prompt Layer reorganizes approved PAL source definitions into a task-specific model-facing representation. It may select, omit, prioritize, restructure, optimize, compress, or resolve conflicts among source conditions. It is not a neutral transport mechanism.

The PAL Prompt Layer must remain:

  • inspectable
  • traceable to its approved source modules
  • distinguishable from the approved PAL source definitions

The three execution-facing blocks are:

  • Identity Block — approved elements that must remain stable across the generation.
  • Scene Variable Block — elements permitted or required to change in the current scene.
  • Anti-drift Block — predicted unintended changes, drift directions, and protected boundaries.

The PAL Prompt Layer may participate in an explicit, designed, and partially observable form of execution-structure mediation by externalizing and structuring part of a transformation path that might otherwise remain implicit. The PAL Prompt Layer does not control or eliminate C. Further mediation may still occur after the Execution Package is produced — including model interpretation, reference-image interpretation, implicit completion, instruction reweighting, safety mediation, product-side transformation, tool constraints, sampling, and probabilistic variation.

Execution Package

The Execution Package is the task-specific model-facing execution artifact produced through the PAL Prompt Layer. It is:

  • derived from approved PAL source definitions
  • not identical to the source modules
  • not identical to A′
  • not automatically authoritative
  • inspectable and traceable where possible

Within a specific generation event, the Execution Package is the model-facing realization of the approved source conditions and generation request. It does not replace the broader approved intent represented by A, and it is not identical to A′.

For the purpose of operational mapping in this architecture:

  • A is represented by the approved intent as instantiated through the applicable PAL conditions and the current generation request.
  • The Execution Package represents the task-specific model-facing realization derived from those conditions.
  • A′ remains the reconstructed task state produced through C-mediated transformation.

This mapping does not redefine A, the Execution Package, or A′ as globally equivalent concepts.

The Execution Package may expose evidence of pre-generation transformation. This may help diagnose aspects of the path from A toward A′, but the Execution Package is not itself A′.

Identity Establishment and Sequence Continuation as Distinct Execution Tasks

Identity establishment and sequence continuation are distinct execution tasks. A Primary Identity Anchor establishes who the subject is; a Current Approved Sequence Reference establishes the state from which the next permitted change proceeds.

The PAL Prompt Layer does not require every approved condition to be fully re-disclosed during every generation step. In sequence continuation, the Current Approved Sequence Reference may carry much of the existing state, while the model-facing execution representation specifies only the permitted delta and the minimum conditions judged necessary to address observed or anticipated drift.

More complete condition disclosure should not be assumed to produce better continuity. In some sequence workflows, full re-disclosure may increase reconstruction pressure and cause the model to rebuild the scene rather than preserve the current approved state. This is recorded as an experimentally testable operational hypothesis and a design consideration, not as a definitive causal claim.

The PAL Prompt Layer may be used for:

  • base-state establishment
  • audit and pre-generation review
  • delta derivation
  • selective re-injection of drifted conditions

Reduced delta-only execution is also an inspectable and traceable task-specific execution representation. When used, it must be recorded as such. It is not defined as a new Layer.

The following distinctions must be preserved:

Primary Identity Anchor
≠ Current Approved Sequence Reference
≠ Validated Identity Anchor

Using a human-approved generated candidate as the Current Approved Sequence Reference does not automatically promote that candidate to a Validated Identity Anchor or incorporate it permanently into the approved source identity.

This operational design consideration is not a redefinition of C. C remains model-side or execution-structure mediation that transforms A into A′. The question of which conditions to include in the model-facing representation is an execution-structure design decision within the existing architecture, not a change to C, CIP, or PAL.

Two Primary Drift Locations Examined by This Hypothesis

For the purpose of this hypothesis, two primary transformation boundaries are examined:

PAL Source Modules → Execution Package
= execution-translation drift

Execution Package → Generated Candidate
= generative reconstruction drift

These are not asserted to be the only possible failure locations in the wider PAL/CIP workflow. They are the two transformation boundaries directly examined by the proposed experiment.

Other failure locations may include:

  • source-definition or source-approval failure
  • intermediate Prompt Layer transformation failure
  • undisclosed product-side processing
  • conformance-assessment error
  • human governance or adoption error

The final output alone cannot always establish which location caused a failure.

Pre-Execution Conformance Check

Before generation, the Initial Execution Package is checked against the PAL source modules to assess whether execution-translation drift has already been introduced.

Primary question:

Does the model-facing Execution Package still preserve the approved PAL source definitions?

This check produces diagnostic evidence only. It does not possess autonomous authority to approve or block generation.

Based on the diagnostic findings, the human operator records one of the following decisions within the CIP-governed workflow:

  • PROCEED — authorizes submission of the reviewed Execution Package for generation. PROCEED does not certify that A has been preserved, and it does not guarantee conformance in the generated candidate.
  • REVISE — requires revision of the Execution Package and another human-governed review before generation.
  • STOP — prevents generation from that Execution Package. The outcome is recorded and remains in the record. A later PROCEED on a revised package does not erase an earlier STOP.

The key distinction is:

  • Assessment = diagnostic evidence produced by the Pre-Execution Conformance Check
  • PROCEED / REVISE / STOP = decisions made by the human operator within the CIP-governed workflow

Both the initially compiled package and any revised package must be retained, and all revisions must be logged.

If the diagnostic check identifies a critical omission, unsupported transformation, protected-condition override, or other material execution-translation risk, the human operator must select REVISE or STOP rather than PROCEED.

Generated Candidate

The generated candidate is provisional and is not automatically an approved result. It may include:

  • valid creative contribution
  • acceptable variation
  • partial conformance
  • unintended drift
  • critical identity failure
  • unauthorized transformation

Not every C-mediated change is an error. The generated candidate must be evaluated rather than adopted automatically.

PAL Conformance Assessment Layer

After generation, the candidate is assessed separately against the source PAL modules.

A single undifferentiated similarity score is not used. Instead, separate diagnostic dimensions are retained:

  • Character conformance
  • Costume conformance
  • Background conformance
  • Sequence continuity
  • Anti-drift compliance
  • Critical identity violations

A high aggregate score must not compensate for a critical failure in a protected identity dimension.

Conformance outputs produced by the PAL Conformance Assessment Layer:

  • are diagnostic evidence only
  • do not redefine the approved PAL source
  • do not approve or reject candidates autonomously
  • do not update the authoritative identity
  • do not convert statistical similarity into governance authority
  • do not replace human judgment
  • do not replace the CIP-governed adoption process

Relationship to C

C is model-side or execution-structure mediation that transforms A into A′.

  • The PAL Prompt Layer is not C as a whole.
  • The PAL Prompt Layer may become part of execution-structure mediation.
  • Further mediation may still occur after the Execution Package is produced.
  • The architecture does not remove C.
  • It makes part of the transformation path more explicit, inspectable, traceable, and diagnosable.

C is not assumed to be directly controllable by CIP. The architecture instead supports the structuring and diagnosis of conditions surrounding C and may expose evidence of C-mediated transformation, while CIP governs the associated workflow conditions. The architecture does not expose or control C in full.

CIP-Governed Validation, Recovery, and Adoption Process

The responsibility boundary in this hypothesis is as follows:

  • PAL Source Modules provide approved continuity and reference conditions.
  • The PAL Prompt Layer translates those conditions into an Initial Execution Package.
  • The Pre-Execution Conformance Check produces diagnostic evidence about possible execution-translation drift.
  • The human operator records PROCEED, REVISE, or STOP within the CIP-governed workflow.
  • A PROCEED decision establishes the Final Execution Package authorized for generation.
  • The generative model produces a candidate.
  • The PAL Conformance Assessment Layer produces post-generation diagnostic evidence about conformance to the approved PAL source definitions.
  • CIP governs validation, rejection, purge, re-binding, re-convergence, and adoption.
  • The human operator retains final adoption authority within that CIP-governed process.

CIP does not directly control C, A′, or the generative model. It governs workflow conditions surrounding the transformation from A to A′ under C and the subsequent treatment of B′.

A candidate, conformance result, optimized prompt, or Execution Package must not become part of the approved source identity merely because it performs well. Incorporation into the approved source identity requires a separate explicit human validation decision and must not be inferred from candidate adoption alone.

Core Distinctions

PAL Source Modules    ≠ PAL Prompt Layer
PAL Source Modules    ≠ Execution Package
Execution Package     ≠ A′
Generated Candidate   ≠ Approved Output
Conformance Diagnosis ≠ Adoption
Diagnostic Evidence   ≠ Governance Decision
C                     ≠ Error
C                     ≠ Creativity Alone
PAL Prompt Layer      ≠ C as a Whole

Testable Claim

This hypothesis proposes a controlled comparison between:

  1. Generation through the pre-existing Direct PAL procedure, without explicit reorganization into the PAL Prompt Layer blocks
  2. Generation through the structured PAL Prompt Layer and its human-governed pre-execution review workflow

Where possible, the following should be held constant:

  • source anchors
  • scene conditions
  • model and version
  • pre-registered execution-unit count
  • planned candidate count
  • session conditions
  • generation settings available to the operator

Realized candidate counts may differ if a registered Condition B execution unit remains finally stopped without reaching generation. Planned and realized counts must therefore be reported separately.

The following should be evaluated:

  • character identity retention
  • correct execution of scene variables
  • reduction of pre-registered predicted drift
  • generation-to-generation variance
  • human adoption rate
  • critical identity violation rate
  • recovery through purge, re-binding, and re-convergence following rejection, in later recovery-focused tests
  • execution-translation drift
  • post-generation conformance

No causal claim is made prior to testing. This document does not assert that the PAL Prompt Layer reduces drift — only that this is a testable hypothesis worth documenting.

See: PAL Prompt Layer Experiment Protocol for the detailed smoke-test protocol.

Limitations

This hypothesis has not yet established that the absence of a structured Prompt Layer caused previously observed PAL instability.

Independent sources of drift may remain, including:

  • model capability
  • anchor quality or impurity
  • context contamination
  • probabilistic variation
  • multi-reference weighting
  • reference-image interpretation
  • conflicts between character, costume, pose, background, and sequence conditions
  • translation loss introduced by the Prompt Layer itself

Final Claim

The architecture does not claim that mediation can be eliminated. Its central claim is that part of the transformation from approved intent to model execution may be made more explicit, inspectable, traceable, and diagnosable, while rejection, recovery, and adoption remain within the CIP-governed process and final adoption authority remains with the human operator.

Status and Next Steps

This document records an experimental hypothesis for further investigation. It is not a finalized PAL specification, and it has not been merged into the core PAL definition.

If validated, this structure may inform future revisions to PAL-supported workflow documentation. Until then, it remains a documented hypothesis available for testing.

See: PAL Hypothesis Document — Column: PAL — Glossary — PAL Prompt Layer Experiment Protocol