PHI-Lens is a constraint interaction protocol for tasks where multiple constraints pull in different directions and a simple flat compromise would hide asymmetry. Rather than resolving constraint tension by averaging or sequencing, PHI-Lens uses concurrent lenses that remain live simultaneously, explicit borders that classify and rank constraints by source and priority, structured assumption tracking with visibility rules, and a gate-based output selector that determines which output mode is valid given what the protocol found. Its purpose is to make asymmetry visible, assign dominance explicitly, and prevent the common failure where a weaker constraint or stylistic preference quietly overrides a harder requirement.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/ai-protocol-kit/llms.txt
Use this file to discover all available pages before exploring further.
When to use it
PHI-Lens distinguishes two operating modes. FIELD_MODE is the default for non-trivial tasks: tasks involving protocol, system design, architecture, critique, red teaming, strategy, conflicting constraints, or multi-constraint generation. Minimal field is used for simple, direct, low-risk, extraction, formatting, narrow transformation, or factual retrieval tasks. If overhead exceeds task value, reduce the active field. If unsure which mode applies, use minimal field.FIELD_MODE is default for non-trivial tasks. PIPELINE_MODE is forbidden when constraints interact.
Key objects
The protocol defines nine core objects. Every active operation in PHI-Lens is described in terms of these objects.| Object | Definition |
|---|---|
| BORDER | An output-limiting constraint |
| ASSUMPTION | A scoped premise used when required information is missing and safe progress remains possible |
| LENS | A task evaluator — a specific analytical function applied to the task |
| GOVERNOR | An active-field limiter that ensures the minimum necessary field is used |
| COUPLING | An asymmetric divergence resolver — assigns DOMINANT and TENSIVE when lenses meaningfully diverge |
| LEDGER | Internal operational state tracking borders, assumptions, lenses, coupling, and unresolved conflicts |
| GATE | Output-mode selector — determines whether to PRODUCE, PRODUCE_WITH_ASSUMPTIONS, PRODUCE_LIMITED, ASK_OP, or SUSPEND_OR_REFUSE |
| FORCE | Internal strength of a BORDER or ASSUMPTION — values are HIGH or LOW |
| COMPOSITE_ASSUMPTION | A visible grouping of non-source-derived assumptions that affect the same target or define a relation between targets |
Borders and priority
Every constraint that limits output must be classified as a BORDER. The classification determines how far a border can be overridden. HIGH_BORDER originates from a higher-priority system, safety, legal, privacy, or tool layer. It overrides style, elegance, proportion, tension, growth, completeness, and compression. If a HIGH_BORDER is active, no lens output, coupling assignment, or stylistic preference may override it. When a HIGH_BORDER conflicts with any other force, the HIGH_BORDER wins. LOW_BORDER originates from an OP-supplied explicit constraint. It holds unless preserving it would violate a HIGH_BORDER, an explicit OP priority that supersedes it, or task executability itself. LOW_BORDER may be demoted, but only through an explicit decision — not silently. FIDELITY_BORDER activates automatically whenever the task uses facts, data, source material, code, law, medicine, finance, current information, named entities, or uploaded files. When active, it prohibits fabrication, alteration of provided data, alteration of quoted or source material, and presentation of inference as fact. Domain-specific border rules apply based on what kind of task is active: factual tasks must preserve the fact/inference separation; technical tasks must preserve behavior, constraints, dependencies, and data semantics; normative tasks must preserve obligations, permissions, prohibitions, and definitions; creative tasks must not present fiction as documented fact; strategic tasks must preserve material assumptions and unequal trade-offs; operational tasks prioritize executability over explanation.The lenses
PHI-Lens maintains a set of evaluator lenses. Some are always active; others activate only when the task requires them. Any lens that does not change output behavior must be deactivated. Always active:INTENT_LENS
INTENT_LENS
Preserves the requested deliverable, format, and explicit OP constraints. If an OP correction contradicts a previous inference, updates active assumptions, borders, and coupling. If the deliverable is ambiguous and an assumption would decide core direction, asks OP. If the deliverable is ambiguous and risk is low, proceeds with an exposed assumption. Handles red team requests by critiquing structure and failure modes. Produces executable rules when a protocol is requested. Removes human-facing explanation when AI-only text is requested.
DOMAIN_LENS
DOMAIN_LENS
Classifies the domain sufficiently to determine which constraints apply. When the domain is mixed, applies the strictest relevant border. Does not introduce unresolved tension in domains that punish ambiguity. Reduces explanation in domains that reward execution. Exposes decision-relevant assumptions in domains that reward auditability. May preserve functional tension in domains that reward creativity.
COMPRESSION_LENS
COMPRESSION_LENS
Deletes redundancy, prose filler, decorative theory, and repeated claims. Converts paragraphs to rules or schemas when possible. Removes non-decision-relevant caveats. Compresses section symmetry that has no function. Converts explanations that replace deliverables into rules, schemas, or output artifacts. Compression must restore function and hierarchy — not merely shorten.
PROPORTION_LENS (activates for multi-part output)
PROPORTION_LENS (activates for multi-part output)
Differentiates weight when unequal parts receive equal treatment. Demotes or compresses overdeveloped secondary material. Expands core material or compresses periphery when core is underdeveloped. Converts lists into hierarchies, rule sets, or schemas when a list replaces structure. Breaks symmetry when symmetry has no function. Must not apply fixed numeric, symbolic, or ratio-based weighting unless OP explicitly requests measured visual or layout proportion.
TENSION_LENS (activates for critique, contrast, adversarial review, design pressure, strategy, system work, or creative force)
TENSION_LENS (activates for critique, contrast, adversarial review, design pressure, strategy, system work, or creative force)
Tension is valid only if it changes decision, hierarchy, interpretation, risk visibility, design direction, compression choice, or operational consequence. Decorative, artificial, or rhetorical tension without function is deleted. Tension that increases ambiguity in a precision domain is deleted. Adds functional opposition when an adversarial task lacks counterforce, or when agreement is flat and critique is required.
GROWTH_LENS (inactive by default)
GROWTH_LENS (inactive by default)
May activate only when OP requests depth and minimal output is insufficient, or when domain completeness or safe interpretation requires expansion. Growth must be non-uniform, must favor high-value branches, and must stop when intent and domain are satisfied. Must not expand by sequence, symmetry, quota, or ornamental structure. Any added section that does not satisfy a named missing requirement, or any material that does not change function, safety, clarity, completeness, or executability, must be deleted or compressed.
EFFECT_LENS (activates for non-trivial deliverables)
EFFECT_LENS (activates for non-trivial deliverables)
Optimizes for executability when output must execute. Preserves decision-relevant trade-offs when output must decide. Preserves pass/fail conditions when output must validate. Preserves discriminating criteria when output must compare. Preserves production constraints when output must generate. Preserves machine-readable structure when output must hand off. Rewrites toward effect when output has content but no operational consequence.
Assumptions
An assumption may be created when required information is missing and safe progress remains possible. Every assumption must meet five validity conditions: it must be specific, correctable by OP, scoped, not circular, and must not hide critical factual gaps or silently decide core direction. When to expose an assumption: if it affects risk, scope, interpretation, validity, or core direction, it must be exposed. If it is non-critical and does not change output interpretation, it may remain internal. Source-material tasks impose additional tracking. When source material is used and a concrete output choice is not source-derived, it must be registered as an assumption tagged with: TARGET (affected component, section, object, claim, or relation), AXIS (position, size, orientation, order, inclusion, label, state, behavior, or relation between components), and SOURCE_STATUS (source-derived, inferred, estimated, placeholder, or fallback). COMPOSITE_ASSUMPTION applies when multiple non-source-derived assumptions affect the same target or define a relation between targets. When the same TARGET has two or more assumption entries where SOURCE_STATUS is not source-derived, a visible COMPOSITE_ASSUMPTION must be created for that TARGET. When multiple TARGETS each have one non-source-derived assumption and those assumptions define a relation between targets, a visible COMPOSITE_ASSUMPTION must be created for that relation. Any assumption with SOURCE_STATUS of placeholder or fallback must be exposed as a visible assumption even if it is the only non-source-derived entry for that TARGET. Forbidden assumptions — the protocol explicitly prohibits assumptions equivalent to:- OP agrees
- Missing data does not matter
- This interpretation is correct
- Risk is low without basis
FIELD_MODE vs minimal field
Active field (FIELD_MODE)
Use when the task involves: protocol, system design, architecture, critique, red teaming, strategy, conflicting constraints, or multi-constraint generation. Keeps all relevant lenses concurrently available until GATE selection. Runs COUPLING when lenses diverge. Checks ledger for COMPOSITE_ASSUMPTION visibility before GATE.
Minimal field
Use when the task is: simple, direct, low-risk, extraction, formatting, narrow transformation, or factual retrieval without structural reasoning. Uses intent, domain, relevant borders, and compression only. If overhead exceeds task value, reduce to minimal field. If unsure which mode applies, use minimal field.
COUPLING
COUPLING is used when active lenses produce meaningful divergence. It is not decoration. It resolves divergence by assigning one DOMINANT force and one TENSIVE force — never by numeric, symbolic, or ratio-based balancing, and never by equal compromise. The DOMINANT force determines the output on incompatible requirements. The TENSIVE force may modify execution but may not reverse the DOMINANT. If the TENSIVE force does not change function, it is removed. Priority rules for DOMINANT assignment: higher-priority instructions or safety take precedence; explicit OP constraints that are safe and relevant are preferred; FIDELITY_BORDER and DOMAIN_BORDER are preferred when involved; deliverable usefulness overrides style. If DOMINANT cannot be selected and the issue is material, the protocol requires asking OP or producing a limited output.Gate selection
The GATE is the output-mode selector. It runs after all lenses, coupling, and ledger checks are complete.PRODUCE
When HARD_PASS and SOFT_PASS both hold. No HIGH_BORDER violation, no hidden critical assumption, no fabrication, no safety or legal violation, no required OP constraint silently ignored. All active LOW_BORDERs handled or explicitly demoted, DOMINANT selected, TENSIVE functional or removed.
PRODUCE_WITH_ASSUMPTIONS
When HARD_PASS holds, useful output is possible, uncertainty is non-blocking, error is reversible or output is marked draft/analysis/hypothesis, and no HIGH_BORDER is affected. Assumptions must be specific, visible when relevant, correctable, and non-circular.
PRODUCE_LIMITED
When HARD_PASS holds, partial output is useful, an unresolved issue affects scope, and safe partial execution remains possible. Any deliverable part that is placeholder, sketch, estimated, fallback, or not fully source-derived must have its scope limit exposed by default.
ASK_OP
When two DOMINANT candidates are incompatible; OP decision determines core direction; missing information is high-impact (changes position, structure, function, priority, responsibility, or interpretation); assumption would decide deliverable; risk is not reversible; or safe reversible assumption cannot preserve progress. Ask the minimum required question only.