This document is outside the current System Core. System Core source collection
CERBERUS_LIGHT_EFFECT-64_Candidate_Semantic_Kernel_Specification_v0.1.docx

Text edition. See the original for figures and page layout.
CERBERUS

LIGHT_EFFECT-64

Candidate Semantic Kernel Specification

Renderer-Neutral Procedural Illumination Application

	CORE SPECIFICATION STATEMENT

LIGHT_EFFECT-64 defines a bounded Spatial / Visual Application Semantic Kernel that maps an accepted typed Effect Signal into a renderer-neutral illumination request. The Kernel declares the light behavior family, destination light parameter, normalized requested intensity envelope, normalized spatial extent, direction/cone interpretation, attenuation/falloff behavior, volumetric participation, shadow participation, color-binding semantics, accumulation/mixing behavior, null/failure handling, local evaluation posture, Formula Profile, and interpretation version.

Field Specification

Field

	Specification

	Document

	CERBERUS LIGHT_EFFECT-64 Candidate Semantic Kernel Specification

	Version

	0.1

	Date

	August 2026

	Series

	LIGHT_EFFECT-64

	Member

	LIGHT_EFFECT-64¹

	Effects Studio Role

	Spatial / Visual Application

	Bounded Question

	How does a procedural Signal control renderer-neutral illumination behavior?

	Output

	Renderer-neutral Illumination Request

	Authoring Basis

	CERBERUS SK Specification Authoring Standard v1.0; Effects Studio SK Interoperability Reference v0.1; current conversation architecture

	Spec Class

	Candidate Spec: semantic contract, Reader topology, Bit allocation, D Classes, DREQs, visual manual, and planning handoff fixed; exact registered D#.# / BOSS / interface records remain implementation promotion gates.

	INTERPRETATION RULE

LIGHT_EFFECT-64 is the Series identity in this document. The mathematical BitGroups are generic SCALAR structures. Light-specific meaning belongs to Reader placements. The Spec is a human-facing compression artifact; once implemented, runtime uses live CERBERUS records directly.

Section Index

Ref.

	Section

	Part 1

	Purpose, scope, illumination ownership, interoperability, and normative laws

	Part 2

	Member architecture, mathematical inventory, Reader topology, and color continuation

	Part 3

	LIGHT_EFFECT-64¹ Reader-role interface specifications

	Part 4

	Interface-0, D requirements, and complete DARTBOARD

	Part 5

	Reader algorithm, typed output, color routing, and interoperability

	Part 6

	Worked examples, invalid states, and conformance

	Part 7

	Planning handoff and promotion gate

	Appendix A

	Complete Reader state enumerations

	Appendix B

	Complete B000:B063 physical Bit map

	Appendix C

	Light Class / Reader applicability guidance

	Appendix D

	Input compatibility and transform matrix

	Appendix E

	Candidate D requirement index

	Appendix F

	Color / Material / Light routing contract

	Appendix G

	Conformance / build checklist

Part 1 — Purpose, Scope, Ownership, Interoperability, and Normative Laws

1. Purpose and Bounded Question

LIGHT_EFFECT-64 is the renderer-neutral illumination application language for the Effects Studio. It answers one bounded question: how does a procedural Signal control illumination behavior? The word is deliberately independent of renderer implementation, world-space light object identity, material surface response, and actual color channel identity.

Figure 1. LIGHT_EFFECT-64¹ Kernel Card.

2. Renderer Separation

Figure 2. Requested illumination versus renderer realization.

A valid LIGHT_EFFECT state is a semantic request. Application Binding resolves target identity, Frame, physical/unit mapping, endpoint capabilities, and renderer connection. This separation allows renderer replacement without rewriting the stored Light semantics.

3. LIGHT / COLOR / MATERIAL Ownership

Figure 3. LIGHT, COLOR, and MATERIAL remain separate semantic owners.

Figure 4. Surface emissive presentation is not automatically illumination emission.

4. Shared-Cause Multimodality

Figure 5. One procedural cause may feed Movement, Light, and Haptic applications while preserving one provenance chain.

5. Spatial Ownership Firewall

Figure 6. Local light geometry does not own world-space placement or target geometry.

6. Ownership and Non-Ownership

LIGHT_EFFECT owns

	LIGHT_EFFECT does not own

	Renderer-neutral illumination family and requested parameter control

	World-space light identity, world position, or canonical Frame identity

	Normalized requested illumination magnitude

	Universal photometric units or endpoint calibration

	Normalized spatial extent / radius

	Target-specific world-unit scale

	Direction/cone interpretation and falloff profile

	Target geometry or renderer-specific light implementation

	Volumetric and shadow participation semantics

	Volume/medium identity, shadow map/ray-tracing implementation, receiver geometry

	Color binding / continuation posture

	Actual RGBA channel identity

	Local light-request accumulation/mixing

	General complete-Signal BLEND_EFFECT algebra

	Null/failure and local evaluation posture

	Global start/duration/repeat/synchronization

7. Normative LIGHT Laws

Law

	Normative statement

	LIGHT-R01 Bounded Illumination

	LIGHT_EFFECT SHALL describe renderer-neutral illumination behavior only.

	LIGHT-R02 Safe Zero

	A1=0 SHALL resolve to OFF / NO LIGHT REQUEST regardless of other stored roles.

	LIGHT-R03 Source Preservation

	LIGHT_EFFECT SHALL NOT rewrite the upstream Effect Signal.

	LIGHT-R04 Renderer Separation

	Endpoint calibration and renderer implementation SHALL remain external.

	LIGHT-R05 Magnitude Non-Authority

	C1 SHALL express normalized requested illumination magnitude, not universal physical output units.

	LIGHT-R06 Spatial Non-Ownership

	Range, direction, cone, and falloff semantics SHALL NOT imply ownership of world position, geometry, or Frame identity.

	LIGHT-R07 Parameter Explicitness

	B1 SHALL identify which light parameter the incoming Signal primarily controls.

	LIGHT-R08 No Silent Coercion

	Signed or Vector inputs SHALL NOT become Scalar light control without an explicit transform/remap.

	LIGHT-R09 Falloff Explicitness

	Spatial attenuation behavior SHALL remain inspectable through F1 or its registered profile.

	LIGHT-R10 Volumetric Separation

	G1 SHALL declare volumetric participation without owning the volume, medium, or volumetric renderer.

	LIGHT-R11 Shadow Separation

	H1 SHALL declare shadow participation without owning target geometry or renderer shadow implementation.

	LIGHT-R12 Color Routing

	Actual color identity SHALL remain external; I1 SHALL route or bind to registered color semantics.

	LIGHT-R13 Mixing Explicitness

	Interaction with other illumination requests SHALL follow J1 rather than renderer-default assumptions.

	LIGHT-R14 Null Visibility

	Missing required source/domain/color/Frame state SHALL remain inspectable.

	LIGHT-R15 Evaluation Locality

	L1 controls local recomputation posture; global performance timing remains external.

	LIGHT-R16 Formula Visibility

	Formula identity/version SHALL remain inspectable wherever mapping behavior changes semantic output.

	LIGHT-R17 Projection Separation

	Preview illumination SHALL remain derived presentation rather than canonical source/world truth.

	LIGHT-R18 Minimum Resolution

	64¹ SHALL remain the minimum complete LIGHT member until genuinely new atomic illumination semantics justify another level.

Part 2 — Member Architecture, Mathematical Inventory, and Reader Topology

8. Minimum Sufficient Resolution

Figure 7. Why LIGHT_EFFECT begins at 64¹.

	RESOLUTION PRINCIPLE

There is no LIGHT_EFFECT-32¹ in this Candidate architecture. A lower member would need to hide or remove parts of the same bounded illumination question. LIGHT_EFFECT-64¹ is therefore the minimum complete member, not an “advanced” version of an implicit 32-bit base.

9. Mathematical BitGroup Inventory

Figure 8. Reusable mathematical inventory used by LIGHT_EFFECT-64¹.

BitGroup

	Width

	Formula / Range

	LIGHT uses

	SCALAR-4

	4

	Σ bᵢ·2ⁱ → 0..15

	Light Class, Parameter, Direction/Cone, Falloff, Volumetric, Shadow, Color, Mixing, Failure, Evaluation, Formula, Version

	SCALAR-8

	8

	Σ bᵢ·2ⁱ → 0..255

	Requested Intensity and Range / Radius

10. Exact Physical Placement Map

Reader

	Physical Bits

	BitGroup

	Semantic role

	A1

	B000:B003

	SCALAR-4

	Light Role / Class

	B1

	B004:B007

	SCALAR-4

	Light Parameter Target

	C1

	B008:B015

	SCALAR-8

	Intensity Range / Requested Magnitude

	D1

	B016:B023

	SCALAR-8

	Range / Radius

	E1

	B024:B027

	SCALAR-4

	Direction / Cone

	F1

	B028:B031

	SCALAR-4

	Attenuation / Falloff

	G1

	B032:B035

	SCALAR-4

	Volumetric Participation

	H1

	B036:B039

	SCALAR-4

	Shadow Participation

	I1

	B040:B043

	SCALAR-4

	Color Binding Mode

	J1

	B044:B047

	SCALAR-4

	Accumulation / Mixing

	K1

	B048:B051

	SCALAR-4

	Null / Failure Behavior

	L1

	B052:B055

	SCALAR-4

	Evaluation Mode

	M1

	B056:B059

	SCALAR-4

	Formula Profile

	N1

	B060:B063

	SCALAR-4

	Version / Reserved

11. Reader Address Topology

Figure 9. Physical order and semantic Reader topology.

12. Parameter Target vs Illumination Envelopes

Figure 10. B1 selects the parameter family while C1–F1 define the illumination envelope and local spatial behavior.

The apparent overlap between Light Parameter Target and dedicated magnitude/space roles is deliberate. B1 identifies which light quantity the incoming procedural Signal primarily controls. C1–F1 provide the bounded semantic envelope and local interpretation used by the selected mapping. This keeps dynamic source routing explicit while preserving stable light-state semantics.

13. Intensity vs Range vs Falloff

Figure 11. Brighter, farther, and different decay are distinct semantic controls.

14. Current Color Continuation

Figure 12. LIGHT routes to current COLOR_EFFECT / COLOR semantics instead of duplicating color identity.

	ARCHITECTURE EVOLUTION

Effects Studio Reference v0.1 predates the current COLOR architecture and names older COLOR targets. This Candidate specialist Spec records the current continuation posture explicitly: LIGHT_EFFECT may route through COLOR_EFFECT-64¹ for procedural color behavior and to COLOR-32-64 for actual registered color state. The historical reference is not silently rewritten.

Part 3 — LIGHT_EFFECT-64¹ Reader-Role Interface Specifications

	FIGURE CONTRACT

Each Reader role is taught through an actual interface control and a semantic consequence viewport before its formal contract table. The document grammar repeats; the semantic visualization changes with the role.

The gallery is intentionally visual-first. The declaration strip identifies the semantic role, Reader address, reusable mathematical carrier, and Candidate D class. The control then demonstrates the intended interaction geometry, while the consequence viewport keeps the underlying scene constant and changes only the Reader variable being taught.

These figures are human-facing compression artifacts of the record architecture. They do not replace the live Reader, D, Formula, BOSS, COLOR, or Application Binding records that will become canonical after implementation.

15. Light Role / Class — A1

Figure 13. Light Role / Class — A1.

	DECLARATION

Light Role / Class | A1 | SCALAR-4 | DREQ-CAT.LIGHT_CLASS

	Property

	Contract

	D Class

	Categorical Selection

	D Requirement Key

	DREQ-CAT.LIGHT_CLASS

	Purpose

	Defines the illumination family under which subsequent roles are interpreted.

	Representative states

	0 OFF / NO REQUEST; 1 EMISSIVE; 2 POINT-LIKE; 3 DIRECTIONAL; 4 AREA / REGION; 5 ENVIRONMENTAL; 6 VOLUMETRIC; 7–15 RESERVED / extension.

	Validation / boundary

	A1=0 is the safe no-op. Class-specific non-applicable controls may be disabled by exact interface rules without mutating stored values.

	Reader formula / mathematics

	SCALAR-4 raw 0..15.

	Does not own

	Target identity, world position, color identity, renderer implementation.

16. Light Parameter Target — B1

Figure 14. Light Parameter Target — B1.

	DECLARATION

Light Parameter Target | B1 | SCALAR-4 | DREQ-CAT.LIGHT_PARAMETER

	Property

	Contract

	D Class

	Categorical Selection

	D Requirement Key

	DREQ-CAT.LIGHT_PARAMETER

	Purpose

	Declares which illumination parameter the accepted Signal primarily drives.

	Representative states

	0 INTENSITY; 1 RANGE; 2 RADIUS; 3 CONE; 4 DIRECTION; 5 ATTENUATION; 6 PROFILE / EXTERNAL; 7–15 RESERVED.

	Validation / boundary

	The selected Formula Profile must support the chosen parameter family. B1 does not replace the dedicated C1–F1 envelope/spatial roles.

	Reader formula / mathematics

	SCALAR-4 raw 0..15.

	Does not own

	Exact target light identity or renderer parameter handle.

17. Intensity Range / Requested Magnitude — C1

Figure 15. Intensity Range / Requested Magnitude — C1.

	DECLARATION

Intensity Range / Requested Magnitude | C1 | SCALAR-8 | DREQ-SCALAR.LIGHT_INTENSITY

	Property

	Contract

	D Class

	Scalar

	D Requirement Key

	DREQ-SCALAR.LIGHT_INTENSITY

	Purpose

	Carries normalized requested illumination magnitude.

	Representative states

	0 → 0.000; 64 → 0.251; 128 → 0.502; 192 → 0.753; 255 → 1.000.

	Validation / boundary

	Physical photometric or endpoint-specific intensity ranges MUST be provided by Formula/Application Binding/endpoint contracts rather than silently encoded here.

	Reader formula / mathematics

	i = C1 / 255.

	Does not own

	Photometric units, endpoint calibration, color, or spatial extent.

18. Range / Radius — D1

Figure 16. Range / Radius — D1.

	DECLARATION

Range / Radius | D1 | SCALAR-8 | DREQ-SCALAR.LIGHT_EXTENT

	Property

	Contract

	D Class

	Scalar

	D Requirement Key

	DREQ-SCALAR.LIGHT_EXTENT

	Purpose

	Carries normalized requested spatial influence extent / radius.

	Representative states

	0 → 0.000; 64 → 0.251; 128 → 0.502; 192 → 0.753; 255 → 1.000.

	Validation / boundary

	The normalized coordinate is Reader semantics. Target-specific world-unit scale remains external.

	Reader formula / mathematics

	r = D1 / 255.

	Does not own

	World-space scale, target geometry, or falloff shape.

19. Direction / Cone — E1

Figure 17. Direction / Cone — E1.

	DECLARATION

Direction / Cone | E1 | SCALAR-4 | DREQ-SPATIAL.LIGHT_DIRECTION_CONE

	Property

	Contract

	D Class

	Spatial Selection

	D Requirement Key

	DREQ-SPATIAL.LIGHT_DIRECTION_CONE

	Purpose

	Declares how directional or conical illumination is oriented in local/supplied spatial context.

	Representative states

	0 BINDING / PROFILE DEFAULT; 1 DIRECTIONAL ORIENTATION; 2 CONE; 3 SUPPLIED DIRECTION; 4 SUPPLIED CONE; 5 SURFACE / NORMAL-ORIENTED; 6 EXTERNAL PROFILE; 7–15 RESERVED.

	Validation / boundary

	Supplied/normal-oriented modes require the referenced Frame, direction, normal, or domain context. Missing required context follows K1.

	Reader formula / mathematics

	SCALAR-4 raw 0..15; exact vectors/cone values remain in supplied context/profile.

	Does not own

	World-space position, canonical Frame identity, or target geometry.

20. Attenuation / Falloff — F1

Figure 18. Attenuation / Falloff — F1.

	DECLARATION

Attenuation / Falloff | F1 | SCALAR-4 | DREQ-PROFILE.LIGHT_FALLOFF

	Property

	Contract

	D Class

	Profile Selection

	D Requirement Key

	DREQ-PROFILE.LIGHT_FALLOFF

	Purpose

	Selects how illumination influence decays within the declared extent.

	Representative states

	0 NONE / UNIFORM; 1 LINEAR; 2 SMOOTH; 3 INVERSE-LIKE; 4 PROFILE / MODEL; 5 EXTERNAL; 6–15 RESERVED.

	Validation / boundary

	Profile/External states require explicit registered profile identity. Falloff does not silently change D1 extent or C1 magnitude.

	Reader formula / mathematics

	SCALAR-4 selects falloff semantics; exact curve mathematics live in the registered profile where required.

	Does not own

	Range, center intensity, or renderer-specific attenuation implementation.

21. Volumetric Participation — G1

Figure 19. Volumetric Participation — G1.

	DECLARATION

Volumetric Participation | G1 | SCALAR-4 | DREQ-CAT.VOLUMETRIC_PARTICIPATION

	Property

	Contract

	D Class

	Participation Selection

	D Requirement Key

	DREQ-CAT.VOLUMETRIC_PARTICIPATION

	Purpose

	Declares how compatible illumination participates in volumetric rendering.

	Representative states

	0 NONE; 1 LOW; 2 FULL; 3 EXTERNALLY DETERMINED; 4 PROFILE / MODEL; 5–15 RESERVED.

	Validation / boundary

	A valid volumetric request does not imply endpoint support. Actual medium/volume identity and renderer capability remain external.

	Reader formula / mathematics

	SCALAR-4 raw 0..15.

	Does not own

	Medium identity, density field, volume geometry, or volumetric renderer implementation.

22. Shadow Participation — H1

Figure 20. Shadow Participation — H1.

	DECLARATION

Shadow Participation | H1 | SCALAR-4 | DREQ-CAT.SHADOW_PARTICIPATION

	Property

	Contract

	D Class

	Participation Selection

	D Requirement Key

	DREQ-CAT.SHADOW_PARTICIPATION

	Purpose

	Declares whether and how shadow semantics participate in the light request.

	Representative states

	0 OFF; 1 ON; 2 TARGET-LIMITED; 3 RUNTIME / PROFILE; 4 EXTERNAL; 5–15 RESERVED.

	Validation / boundary

	TARGET-LIMITED requires explicit target/receiver context. Missing target does not authorize guessing receiver geometry.

	Reader formula / mathematics

	SCALAR-4 raw 0..15.

	Does not own

	Occluder/receiver geometry, shadow-map resolution, ray-tracing implementation.

23. Color Binding Mode — I1

Figure 21. Color Binding Mode — I1.

	DECLARATION

Color Binding Mode | I1 | SCALAR-4 | DREQ-ROUTE.LIGHT_COLOR

	Property

	Contract

	D Class

	Semantic Route / Binding

	D Requirement Key

	DREQ-ROUTE.LIGHT_COLOR

	Purpose

	Declares how the illumination request obtains color behavior or registered color identity.

	Representative states

	0 NONE / ENDPOINT DEFAULT; 1 FIXED REGISTERED COLOR; 2 PALETTE; 3 FIELD-DRIVEN; 4 EXTERNAL COLOR_EFFECT; 5 DIRECT COLOR-32-64; 6 PROFILE / EXTERNAL; 7–15 RESERVED.

	Validation / boundary

	Modes requiring color references or COLOR_EFFECT routes must resolve them explicitly. Missing required color context follows K1.

	Reader formula / mathematics

	SCALAR-4 selects routing/binding semantics.

	Does not own

	RGBA channel identity; that remains in COLOR-32-64 or other registered color records.

24. Accumulation / Mixing — J1

Figure 22. Accumulation / Mixing — J1.

	DECLARATION

Accumulation / Mixing | J1 | SCALAR-4 | DREQ-OP.LIGHT_MIX

	Property

	Contract

	D Class

	Operator Selection

	D Requirement Key

	DREQ-OP.LIGHT_MIX

	Purpose

	Declares how this illumination request coexists with other compatible light requests in the same application scope.

	Representative states

	0 ADD; 1 MAX; 2 REPLACE; 3 EXTERNALLY MIXED; 4 PRIORITY; 5–15 RESERVED.

	Validation / boundary

	This is light-request coexistence, not general complete-Signal BLEND_EFFECT algebra. External mixing requires an explicit mixer/binding contract.

	Reader formula / mathematics

	SCALAR-4 raw 0..15.

	Does not own

	General Signal blend mathematics or renderer-default light accumulation.

25. Null / Failure Behavior — K1

Figure 23. Null / Failure Behavior — K1.

	DECLARATION

Null / Failure Behavior | K1 | SCALAR-4 | DREQ-POLICY.FAILURE

	Property

	Contract

	D Class

	Failure Policy

	D Requirement Key

	DREQ-POLICY.FAILURE

	Purpose

	Defines visible behavior when required source, Frame, target, color route, profile, or other context is missing/invalid.

	Representative states

	0 UNRESOLVED / NO LIGHT REQUEST; 1 ZERO INTENSITY; 2 HOLD LAST VALID; 3 SUPPRESS APPLICATION; 4 ERROR; 5 EXTERNAL POLICY; 6–15 RESERVED.

	Validation / boundary

	Fallback outputs SHALL preserve validity/provenance. A numeric fallback never makes missing context valid.

	Reader formula / mathematics

	SCALAR-4 raw 0..15.

	Does not own

	Fabricated Frame, color, target, or source values.

26. Evaluation Mode — L1

Figure 24. Evaluation Mode — L1.

	DECLARATION

Evaluation Mode | L1 | SCALAR-4 | DREQ-EVAL.MODE

	Property

	Contract

	D Class

	Evaluation State

	D Requirement Key

	DREQ-EVAL.MODE

	Purpose

	Declares when the local light request recomputes against supplied source/domain context.

	Representative states

	0 LIVE; 1 SNAPSHOT; 2 SAMPLE_AND_HOLD; 3 EVENT_DRIVEN; 4–15 RESERVED.

	Validation / boundary

	SAMPLE_AND_HOLD and EVENT_DRIVEN require explicit sample/event trigger context. Global start/duration/repetition remain external.

	Reader formula / mathematics

	SCALAR-4 raw 0..15.

	Does not own

	Global timing, synchronization, or source Signal lifecycle.

27. Formula Profile — M1

Figure 25. Formula Profile — M1.

	DECLARATION

Formula Profile | M1 | SCALAR-4 | DREQ-PROFILE.LIGHT_FORMULA

	Property

	Contract

	D Class

	Profile Selection

	D Requirement Key

	DREQ-PROFILE.LIGHT_FORMULA

	Purpose

	Selects the registered mapping that turns the accepted typed Signal into the selected light parameter semantics.

	Representative states

	0 DIRECT / BINDING DEFAULT; 1 SCALAR→INTENSITY; 2 SIGNED SCALAR→INTENSITY REMAP; 3 SCALAR→RANGE/RADIUS; 4 SCALAR→CONE PARAMETER; 5 FIELD→PER-ELEMENT LIGHT; 6 EVENT→FLASH REQUEST; 7 MASK→PARTICIPATION/INTENSITY; 8 FIELD→VOLUMETRIC CONTROL; 9 EXTERNAL LIGHT FORMULA; 10–15 RESERVED.

	Validation / boundary

	Each profile must register accepted input class, required context, exact equation/version, undefined conditions, output semantics, and deterministic posture.

	Reader formula / mathematics

	SCALAR-4 selects Formula Profile identity/class; exact equation lives in the profile record.

	Does not own

	Renderer implementation or hidden unit conversion.

28. Interpretation Version — N1

Figure 26. Interpretation Version — N1.

	DECLARATION

Interpretation Version | N1 | SCALAR-4 | DREQ-META.VERSION_INSPECT

	Property

	Contract

	D Class

	Metadata Inspection

	D Requirement Key

	DREQ-META.VERSION_INSPECT

	Purpose

	Pins the Reader interpretation required to resolve historical stored Bits and routing/profile relationships.

	Representative states

	0 baseline Candidate interpretation; 1–14 registered future interpretations; 15 RESERVED.

	Validation / boundary

	Ordinary DARTBOARD presentation is read-only. Migration/version conversion is a separate governed operation.

	Reader formula / mathematics

	SCALAR-4 raw 0..15.

	Does not own

	Spec document version, Formula Profile version, target asset version, or renderer version.

Part 4 — Interface-0, D Requirements, and Complete DARTBOARD

29. Interface-0 Assembly

Figure 27. Interface-0 assembly for Direction / Cone.

30. Complete Generated LIGHT DARTBOARD

Figure 28. Complete LIGHT_EFFECT-64¹ illumination authoring surface.

The top binding strip is runtime context rather than another BitWord placement. The left column exposes the Reader roles using the interface forms established in the role gallery, the center provides derived illumination inspection, and the right column shows deterministic Reader resolution and typed output.

31. One Control Descends to Exact Bits

Figure 29. C1 Intensity descends from interface control to Reader semantics, SCALAR-8 mathematics, and exact B008:B015 Bits.

32. Complete Physical BitWord Map

Figure 30. Complete LIGHT_EFFECT-64¹ B000:B063 map.

33. Candidate D Requirement Plan

Reader

	D Class

	Candidate requirement

	A1

	Categorical Selection

	DREQ-CAT.LIGHT_CLASS

	B1

	Categorical Selection

	DREQ-CAT.LIGHT_PARAMETER

	C1

	Scalar

	DREQ-SCALAR.LIGHT_INTENSITY

	D1

	Scalar

	DREQ-SCALAR.LIGHT_EXTENT

	E1

	Spatial Selection

	DREQ-SPATIAL.LIGHT_DIRECTION_CONE

	F1

	Profile Selection

	DREQ-PROFILE.LIGHT_FALLOFF

	G1

	Participation Selection

	DREQ-CAT.VOLUMETRIC_PARTICIPATION

	H1

	Participation Selection

	DREQ-CAT.SHADOW_PARTICIPATION

	I1

	Semantic Route / Binding

	DREQ-ROUTE.LIGHT_COLOR

	J1

	Operator Selection

	DREQ-OP.LIGHT_MIX

	K1

	Failure Policy

	DREQ-POLICY.FAILURE

	L1

	Evaluation State

	DREQ-EVAL.MODE

	M1

	Profile Selection

	DREQ-PROFILE.LIGHT_FORMULA

	N1

	Metadata Inspection

	DREQ-META.VERSION_INSPECT

Part 5 — Reader Algorithm, Typed Output, Color Routing, and Interoperability

34. Reader Evaluation Pipeline

Figure 31. LIGHT Reader pipeline.

35. Renderer-Neutral Illumination Request

Figure 32. Example typed Illumination Request and deliberately absent implementation-owned fields.

36. Direct Compatibility and Explicit Transforms

Figure 33. Scalar direct compatibility versus declared Signed/Vector transforms.

	NO SILENT COERCION

A Vector does not become light intensity merely because magnitude is calculable. Signed Scalar does not become positive intensity merely because rectification is available. The transform/remap is itself semantic structure and must remain visible.

37. Interoperability Card

Figure 34. LIGHT_EFFECT interoperability card.

38. Continuation, Compound, and Runtime Graph

Figure 35. Semantic continuation, Compound membership, and runtime signal flow are distinct grammars.

39. Endpoint Capability Boundary

Figure 36. Semantic validity remains distinct from renderer/endpoint capability.

40. Determinism Posture

LIGHT_EFFECT adds no intrinsic stochastic behavior, so this Candidate architecture stores no separate Determinism Reader. Determinism derives from upstream Signal state, the selected Formula Profile, local Evaluation Mode, supplied context, and Application Binding. A deterministic source with deterministic Formula/context yields a deterministic Light Request; stochastic source state remains stochastic downstream. This avoids a redundant stored claim that could contradict provenance.

Part 6 — Worked Examples, Invalid States, and Conformance

41. Worked Example Triptych

Figure 37. Minimal, rich, and cross-SK LIGHT examples.

42. Minimal Example — Scalar Point Light

Reader

	Resolved state

	A1

	POINT-LIKE

	B1

	INTENSITY

	C1

	.65 requested magnitude

	D1

	.40 normalized extent

	E1

	Binding default

	F1

	SMOOTH

	G1

	NONE

	H1

	OFF

	I1

	ENDPOINT DEFAULT

	J1

	ADD

	K1

	UNRESOLVED / NO REQUEST on failure

	L1

	LIVE

	M1

	SCALAR→INTENSITY

	N1

	baseline

43. Rich Example — Dragon Scale Shimmer

FIELD_EFFECT evaluates the Dragon Scale domain into a shared Shimmer Field consumed by Movement, Color, and LIGHT. A representative Light branch uses EMISSIVE, INTENSITY, FIELD→PER-ELEMENT LIGHT, SURFACE NORMAL, SMOOTH falloff, external COLOR_EFFECT, and ADD mixing. The Light request is one projection; the Shimmer Field remains available and unchanged.

44. Cross-SK Example — Resonance Cloud

A Resonance Event can feed Light intensity/coherence while the same provenance drives Geometry, Haptic, Audio, and Color branches. The point is not that LIGHT knows resonance semantics; rather, the accepted typed source and Formula Profile map declared resonance values into light-request semantics. This preserves shared cause without duplicating source truth.

45. MATERIAL Emissive Continuation

Figure 38. MATERIAL emissive presentation routes to LIGHT only when actual illumination semantics are required.

46. Invalid Directional Context

Figure 39. Missing supplied Direction / Frame leaves directional semantics unresolved.

47. Missing Color Route

Figure 40. Explicit color route missing: LIGHT does not invent color identity.

48. Target-Limited Shadow Without Target

Figure 41. TARGET-LIMITED shadow semantics require an explicit receiver context.

49. Valid Semantics, Unsupported Endpoint

Figure 42. A renderer capability mismatch does not retroactively invalidate the LIGHT semantic request.

50. Minimum Sufficient Resolution Gate

Figure 43. A future level must earn existence through genuinely new atomic LIGHT capability.

Part 7 — Planning Handoff and Promotion Gate

51. Deterministic Planning Manifest

Figure 44. Human-facing record-construction manifest.

52. Records Required for Implementation

Record group

	Planning requirement

	Mathematical BitGroups

	Reuse existing SCALAR-4 and SCALAR-8 mathematics; do not create light-specific duplicates.

	LIGHT_EFFECT-64¹ BitWord

	Create the exact B000:B063 placements A1:N1 defined here.

	Reader Enumerations

	Register class, parameter, spatial, falloff, participation, color-route, mixing, failure, evaluation, formula, and version vocabularies.

	Formula Profiles

	Register exact equation identity/version, accepted typed inputs, required domain/Frame state, output semantics, undefined conditions, and deterministic posture.

	Application Binding

	Resolve exact target light/application identity, Frame, physical/unit mapping, color references, capability policy, endpoint, and provenance.

	Color Continuation

	Bind current COLOR_EFFECT-64¹ / COLOR-32-64 semantic routes where required; preserve historical architecture evolution notes.

	D Contracts

	Resolve Candidate DREQs to exact registered D#.# contracts.

	BOSS / Interface Metadata

	Bind symbols, labels, role colors, and generated interface treatment without making them semantic identity.

	Validation

	Implement input compatibility, missing context, color-route, shadow-target, extent/falloff, and endpoint-capability separation checks.

	Tests

	Run conformance matrix, renderer replacement, shared provenance, invalid context, endpoint capability, and DARTBOARD reconstruction tests.

53. Candidate → Formal Promotion Gate

	PROMOTION GATE

Formal promotion requires exact registered D#.# bindings; finalized Reader enumeration records; approved Formula Profile identities/versions; current COLOR continuation routes; BOSS/interface records; Application Binding contracts; input transform validation; missing-context behavior; endpoint-capability policy; conformance tests; and verification that the DARTBOARD can be regenerated from live records.

54. Human-Learning Completion Test

A knowledgeable human should be able to return to this manual months later, skim the figures, and recover the correct mental model: LIGHT_EFFECT turns a typed procedural cause into a renderer-neutral illumination request; it separates intensity, extent, direction, falloff, volumetric participation, shadows, color routing, and mixing; it does not become COLOR, MATERIAL, geometry, world placement, renderer implementation, or endpoint calibration.

If the BitWord has not yet been built, this Spec provides a planning map for the records and validations that must exist. Once built, the live CERBERUS records are the machine; this document remains the compressed human instruction manual.

Appendix A — Complete Reader State Enumerations

Reader role

	Enumeration / formula

	A1 Light Class

	0 OFF/NO_REQUEST; 1 EMISSIVE; 2 POINT_LIKE; 3 DIRECTIONAL; 4 AREA/REGION; 5 ENVIRONMENTAL; 6 VOLUMETRIC; 7–15 RESERVED/extension

	B1 Parameter Target

	0 INTENSITY; 1 RANGE; 2 RADIUS; 3 CONE; 4 DIRECTION; 5 ATTENUATION; 6 PROFILE/EXTERNAL; 7–15 RESERVED

	C1 Intensity

	0–255; i=C1/255

	D1 Range/Radius

	0–255; r=D1/255

	E1 Direction/Cone

	0 BINDING/PROFILE_DEFAULT; 1 DIRECTIONAL_ORIENTATION; 2 CONE; 3 SUPPLIED_DIRECTION; 4 SUPPLIED_CONE; 5 SURFACE/NORMAL_ORIENTED; 6 EXTERNAL_PROFILE; 7–15 RESERVED

	F1 Falloff

	0 NONE/UNIFORM; 1 LINEAR; 2 SMOOTH; 3 INVERSE_LIKE; 4 PROFILE/MODEL; 5 EXTERNAL; 6–15 RESERVED

	G1 Volumetric

	0 NONE; 1 LOW; 2 FULL; 3 EXTERNALLY_DETERMINED; 4 PROFILE/MODEL; 5–15 RESERVED

	H1 Shadow

	0 OFF; 1 ON; 2 TARGET_LIMITED; 3 RUNTIME/PROFILE; 4 EXTERNAL; 5–15 RESERVED

	I1 Color Binding

	0 NONE/ENDPOINT_DEFAULT; 1 FIXED_REGISTERED_COLOR; 2 PALETTE; 3 FIELD_DRIVEN; 4 EXTERNAL_COLOR_EFFECT; 5 DIRECT_COLOR_32_64; 6 PROFILE/EXTERNAL; 7–15 RESERVED

	J1 Mixing

	0 ADD; 1 MAX; 2 REPLACE; 3 EXTERNALLY_MIXED; 4 PRIORITY; 5–15 RESERVED

	K1 Failure

	0 UNRESOLVED/NO_LIGHT_REQUEST; 1 ZERO_INTENSITY; 2 HOLD_LAST_VALID; 3 SUPPRESS_APPLICATION; 4 ERROR; 5 EXTERNAL_POLICY; 6–15 RESERVED

	L1 Evaluation

	0 LIVE; 1 SNAPSHOT; 2 SAMPLE_AND_HOLD; 3 EVENT_DRIVEN; 4–15 RESERVED

	M1 Formula

	0 DIRECT/BINDING_DEFAULT; 1 SCALAR→INTENSITY; 2 SIGNED_SCALAR→INTENSITY_REMAP; 3 SCALAR→RANGE/RADIUS; 4 SCALAR→CONE_PARAMETER; 5 FIELD→PER_ELEMENT_LIGHT; 6 EVENT→FLASH_REQUEST; 7 MASK→PARTICIPATION/INTENSITY; 8 FIELD→VOLUMETRIC_CONTROL; 9 EXTERNAL_LIGHT_FORMULA; 10–15 RESERVED

	N1 Version

	0 baseline Candidate interpretation; 1–14 registered future interpretations; 15 RESERVED

Appendix B — Complete B000:B063 Physical Bit Map

Global Bit

	Reader

	BitGroup

	Local Bit

	Contribution

	Reader interpretation

	B000

	A1

	SCALAR-4

	0

	1

	Light Role / Class

	B001

	A1

	SCALAR-4

	1

	2

	Light Role / Class

	B002

	A1

	SCALAR-4

	2

	4

	Light Role / Class

	B003

	A1

	SCALAR-4

	3

	8

	Light Role / Class

	B004

	B1

	SCALAR-4

	0

	1

	Light Parameter Target

	B005

	B1

	SCALAR-4

	1

	2

	Light Parameter Target

	B006

	B1

	SCALAR-4

	2

	4

	Light Parameter Target

	B007

	B1

	SCALAR-4

	3

	8

	Light Parameter Target

	B008

	C1

	SCALAR-8

	0

	1

	Intensity Range / Requested Magnitude

	B009

	C1

	SCALAR-8

	1

	2

	Intensity Range / Requested Magnitude

	B010

	C1

	SCALAR-8

	2

	4

	Intensity Range / Requested Magnitude

	B011

	C1

	SCALAR-8

	3

	8

	Intensity Range / Requested Magnitude

	B012

	C1

	SCALAR-8

	4

	16

	Intensity Range / Requested Magnitude

	B013

	C1

	SCALAR-8

	5

	32

	Intensity Range / Requested Magnitude

	B014

	C1

	SCALAR-8

	6

	64

	Intensity Range / Requested Magnitude

	B015

	C1

	SCALAR-8

	7

	128

	Intensity Range / Requested Magnitude

	B016

	D1

	SCALAR-8

	0

	1

	Range / Radius

	B017

	D1

	SCALAR-8

	1

	2

	Range / Radius

	B018

	D1

	SCALAR-8

	2

	4

	Range / Radius

	B019

	D1

	SCALAR-8

	3

	8

	Range / Radius

	B020

	D1

	SCALAR-8

	4

	16

	Range / Radius

	B021

	D1

	SCALAR-8

	5

	32

	Range / Radius

Appendix B — Complete B000:B063 Physical Bit Map (continued)

Global Bit

	Reader

	BitGroup

	Local Bit

	Contribution

	Reader interpretation

	B022

	D1

	SCALAR-8

	6

	64

	Range / Radius

	B023

	D1

	SCALAR-8

	7

	128

	Range / Radius

	B024

	E1

	SCALAR-4

	0

	1

	Direction / Cone

	B025

	E1

	SCALAR-4

	1

	2

	Direction / Cone

	B026

	E1

	SCALAR-4

	2

	4

	Direction / Cone

	B027

	E1

	SCALAR-4

	3

	8

	Direction / Cone

	B028

	F1

	SCALAR-4

	0

	1

	Attenuation / Falloff

	B029

	F1

	SCALAR-4

	1

	2

	Attenuation / Falloff

	B030

	F1

	SCALAR-4

	2

	4

	Attenuation / Falloff

	B031

	F1

	SCALAR-4

	3

	8

	Attenuation / Falloff

	B032

	G1

	SCALAR-4

	0

	1

	Volumetric Participation

	B033

	G1

	SCALAR-4

	1

	2

	Volumetric Participation

	B034

	G1

	SCALAR-4

	2

	4

	Volumetric Participation

	B035

	G1

	SCALAR-4

	3

	8

	Volumetric Participation

	B036

	H1

	SCALAR-4

	0

	1

	Shadow Participation

	B037

	H1

	SCALAR-4

	1

	2

	Shadow Participation

	B038

	H1

	SCALAR-4

	2

	4

	Shadow Participation

	B039

	H1

	SCALAR-4

	3

	8

	Shadow Participation

	B040

	I1

	SCALAR-4

	0

	1

	Color Binding Mode

	B041

	I1

	SCALAR-4

	1

	2

	Color Binding Mode

	B042

	I1

	SCALAR-4

	2

	4

	Color Binding Mode

	B043

	I1

	SCALAR-4

	3

	8

	Color Binding Mode

Appendix B — Complete B000:B063 Physical Bit Map (continued)

Global Bit

	Reader

	BitGroup

	Local Bit

	Contribution

	Reader interpretation

	B044

	J1

	SCALAR-4

	0

	1

	Accumulation / Mixing

	B045

	J1

	SCALAR-4

	1

	2

	Accumulation / Mixing

	B046

	J1

	SCALAR-4

	2

	4

	Accumulation / Mixing

	B047

	J1

	SCALAR-4

	3

	8

	Accumulation / Mixing

	B048

	K1

	SCALAR-4

	0

	1

	Null / Failure

	B049

	K1

	SCALAR-4

	1

	2

	Null / Failure

	B050

	K1

	SCALAR-4

	2

	4

	Null / Failure

	B051

	K1

	SCALAR-4

	3

	8

	Null / Failure

	B052

	L1

	SCALAR-4

	0

	1

	Evaluation Mode

	B053

	L1

	SCALAR-4

	1

	2

	Evaluation Mode

	B054

	L1

	SCALAR-4

	2

	4

	Evaluation Mode

	B055

	L1

	SCALAR-4

	3

	8

	Evaluation Mode

	B056

	M1

	SCALAR-4

	0

	1

	Formula Profile

	B057

	M1

	SCALAR-4

	1

	2

	Formula Profile

	B058

	M1

	SCALAR-4

	2

	4

	Formula Profile

	B059

	M1

	SCALAR-4

	3

	8

	Formula Profile

	B060

	N1

	SCALAR-4

	0

	1

	Version

	B061

	N1

	SCALAR-4

	1

	2

	Version

	B062

	N1

	SCALAR-4

	2

	4

	Version

	B063

	N1

	SCALAR-4

	3

	8

	Version

Appendix C — Light Class / Reader Applicability Guidance

Light Class

	Commonly applicable Reader semantics

	Boundary note

	OFF

	All roles stored but output forced to no request.

	A1=0 short-circuits output.

	EMISSIVE

	Intensity, extent, surface/normal orientation, color, mixing.

	Actual surface geometry and material emissive state remain external.

	POINT-LIKE

	Intensity, range/radius, falloff, volume, shadow, color, mixing.

	Exact point position from binding.

	DIRECTIONAL

	Intensity, supplied direction/Frame, shadow, color, mixing.

	Range may be non-applicable or profile-specific.

	AREA / REGION

	Intensity, region extent, orientation, falloff/profile, shadow, color.

	Actual region/geometry external.

	ENVIRONMENTAL

	Intensity, color, mixing, optional profile/volume.

	No implicit world probe/environment identity.

	VOLUMETRIC

	Intensity, extent, direction/cone, falloff, color, volume participation.

	Actual volume/medium and renderer external.

	GUIDANCE ONLY

This table is a human-facing applicability guide. Exact Formula Profile and D-contract rules are authoritative once registered. Non-applicable controls may be disabled/collapsed without mutating their stored Bits.

Appendix D — Input Compatibility and Transform Matrix

Input Signal Class

	Posture

	Requirement

	Scalar

	DIRECT

	Direct Scalar light Formula/Profile may consume it.

	Field

	DIRECT under declared profile

	Per-element / domain-aware light profiles may consume the Field directly.

	Event

	DIRECT under event profile

	Event→Flash or event-triggered light profile.

	Mask

	DIRECT under declared profile

	Participation/intensity mapping when profile expects Mask semantics.

	Signed Scalar

	REMAP REQUIRED

	Explicit rectify/remap/signed-compatible Light Formula; no silent positive-intensity coercion.

	Vector

	TRANSFORM REQUIRED

	Magnitude or component transform first; resulting Scalar/Signed Scalar then follows compatible path.

	Probability

	PROFILE / TRANSFORM REQUIRED

	Only when an exact Light Formula declares probability interpretation.

	Angular / Orientation

	CONTEXT / PROFILE REQUIRED

	May supply direction/orientation semantics but must not silently become intensity.

Appendix E — Candidate D Requirement Index

Reader

	Semantic role

	D Class

	Candidate requirement

	A1

	Light Role / Class

	Categorical Selection

	DREQ-CAT.LIGHT_CLASS

	B1

	Light Parameter Target

	Categorical Selection

	DREQ-CAT.LIGHT_PARAMETER

	C1

	Intensity Range / Requested Magnitude

	Scalar

	DREQ-SCALAR.LIGHT_INTENSITY

	D1

	Range / Radius

	Scalar

	DREQ-SCALAR.LIGHT_EXTENT

	E1

	Direction / Cone

	Spatial Selection

	DREQ-SPATIAL.LIGHT_DIRECTION_CONE

	F1

	Attenuation / Falloff

	Profile Selection

	DREQ-PROFILE.LIGHT_FALLOFF

	G1

	Volumetric Participation

	Participation Selection

	DREQ-CAT.VOLUMETRIC_PARTICIPATION

	H1

	Shadow Participation

	Participation Selection

	DREQ-CAT.SHADOW_PARTICIPATION

	I1

	Color Binding Mode

	Semantic Route / Binding

	DREQ-ROUTE.LIGHT_COLOR

	J1

	Accumulation / Mixing

	Operator Selection

	DREQ-OP.LIGHT_MIX

	K1

	Null / Failure Behavior

	Failure Policy

	DREQ-POLICY.FAILURE

	L1

	Evaluation Mode

	Evaluation State

	DREQ-EVAL.MODE

	M1

	Formula Profile

	Profile Selection

	DREQ-PROFILE.LIGHT_FORMULA

	N1

	Version / Reserved

	Metadata Inspection

	DREQ-META.VERSION_INSPECT

Appendix F — Color / Material / Light Routing Contract

Relationship

	Meaning

	Not implied

	LIGHT_EFFECT <R> COLOR_EFFECT-64¹

	Light requires procedural color behavior such as palette mapping or field-driven color.

	COLOR_EFFECT membership inside LIGHT or duplicated palette state.

	LIGHT_EFFECT <R> COLOR-32-64

	Light requires a fixed registered color identity/state.

	RGBA Bits copied into LIGHT_EFFECT.

	MATERIAL_EFFECT <R> LIGHT_EFFECT

	Surface emissive or material behavior requires actual illumination semantics.

	Every emissive-looking material automatically emits scene light.

	MATERIAL_EFFECT <R> COLOR_EFFECT / COLOR

	Material needs color behavior or registered color state.

	Material becomes the owner of COLOR identity.

	Runtime Graph: FIELD → LIGHT

	A producer Signal controls Light through a graph edge.

	Semantic continuation or Compound membership.

	Compound |[▪︎|▪︎]|

	Complete LIGHT word is a constituent of a saved Effect Assembly.

	Runtime execution order or continuation meaning.

Appendix G — Conformance / Build Checklist

□ B000:B063 allocation matches the approved LIGHT_EFFECT-64¹ map.

□ SCALAR-4 and SCALAR-8 are reused as generic mathematics rather than light-specific duplicate BitGroups.

□ A1=0 yields safe OFF / no Illumination Request.

□ Every Reader role has a registered definition, enumeration or Reader formula, validation rule, and non-ownership boundary.

□ C1 and D1 are normalized Reader semantics, not universal physical-unit claims.

□ B1 parameter target is compatible with the selected Formula Profile and required context.

□ Signed Scalar input never silently becomes positive intensity; declared remap/rectification is explicit.

□ Vector input never silently becomes Scalar; magnitude/component transform is explicit.

□ Supplied Direction/Cone modes validate Frame/orientation context and never fabricate world-space values.

□ Falloff profile identity/version is inspectable where required.

□ Volumetric participation remains separate from medium identity and endpoint capability.

□ Shadow participation remains separate from occluder/receiver geometry and renderer shadow implementation.

□ Color binding routes to current COLOR_EFFECT-64¹ / COLOR-32-64 records and does not duplicate RGBA state.

□ J1 light-request mixing is not substituted for BLEND_EFFECT Signal algebra.

□ K1 fallbacks preserve invalid/missing status and provenance.

□ L1 evaluation does not claim global timing ownership.

□ Formula Profiles declare accepted inputs, exact equations, required domain state, undefined conditions, output semantics, and determinism.

□ Endpoint capability mismatch is handled externally and does not silently mutate LIGHT semantic state.

□ Candidate DREQs are resolved to exact D#.# before Formal promotion.

□ BOSS symbols and interface profiles are bound without becoming semantic identity.

□ DARTBOARD can be regenerated from live records and is treated as a disposable human-facing projection.

□ Rendered instruction manual has been visually inspected for figure legibility, clipping, and semantic clarity.

	PRODUCTION PRINCIPLE

The records are the machine. The Spec is the human compression artifact. LIGHT_EFFECT stays compact because illumination semantics live in the 64-bit word while exact target identity, Frame, units, color records, capability policy, and renderer realization remain explicit in their proper owners.