Conditional Visibility, Access Control, and Audience-Aware Retrieval
Not all answers are for everyone.
Not all knowledge applies universally.
Not all logic is unconditional.
That’s why agentic systems need more than answers—
They need publishing scaffolds that define who the answer is for, when it applies, and under what limits.
You can’t do that with Markdown alone.
You do it with conditional fragments.
This chapter introduces the three logic-bound content types that shape contextual retrieval:
- PolicyFragments → Define limitations, rights, exceptions
- PersonaFragments → Define the audience context for agent alignment
- EligibilityFragments → Gate logic based on criteria
Together, these fragments govern agent reasoning—at the edge of AI visibility.
What Is a PolicyFragment?
A PolicyFragment encodes structured conditions around rights, limitations, inclusions, or exclusions—used to inform AI agents when a rule applies, and when it doesn’t.
It’s not legal boilerplate.
It’s machine-readable logic embedded inside memory.
Example: PolicyFragment (YAML-in-HTML)
<template data-visibility-fragment>
FragmentType: PolicyFragment
Title: Out-of-Network Drug Coverage Limitation
AppliesTo:
– PlanType: Medicare Advantage
– Coverage: Prescription Drugs
Rules:
– If: service_location == “OutOfNetwork”
Then: “Only Tier 1 drugs may be covered, with prior authorization.”
– If: tier in [2, 3, 4] AND service_location == “OutOfNetwork”
Then: “Coverage not available. Enrollee pays full cost.”
Exclusions:
– States: [NY, CA, MA]
– Note: “State-level override applies for dual-eligible plans.”
EffectiveDate: 2025-01-01
Provenance: MedicareWire Plan Data, PBP v17
trust_layer: policy-declaration
</template>
Key Fields:
| Field | Description |
| AppliesTo | Defines the entity or coverage domain |
| Rules | Structured logic conditions |
| Exclusions | Optional overrides |
| EffectiveDate | Temporal anchor for policy validity |
| trust_layer | Declares trust confidence (policy-declaration, factual-core, etc.) |
What Is a PersonaFragment?
A PersonaFragment defines the attributes, role, or audience a particular response, term, or policy should apply to—so agents can reflect content with contextual accuracy.
Agents need to know:
- Who’s asking
- What persona they represent
- What knowledge is relevant
- What language to use
- What logic to prioritize
PersonaFragments help agents scope reflection, filter answers, and align communication tone.
Example: PersonaFragment
<template data-visibility-fragment>
FragmentType: PersonaFragment
PersonaID: caregiver-elderly-parent
Description: Adult caregiver helping their parent navigate Medicare options.
Attributes:
– Role: Caregiver
– Relationship: Parent/Child
– NeedsSimplifiedLanguage: true
– NeedsFollowupPrompts: true
PreferredFragments:
– GlossaryTerms: [Medicare Advantage, Extra Help]
– Explainers: [Dental Coverage, Dual-Eligibility]
– Policies: [Enrollment Window Exceptions]
Provenance: TrustPublishing.com/definitions/personas
trust_layer: defined-term
</template>
Agents use this to:
- Modify reflection tone
- Choose which fragments to retrieve
- Trigger gated ExplainerFragments
- Avoid overwhelming the user
You’re publishing agent-facing context scaffolds—not just help content.
What Is an EligibilityFragment?
An EligibilityFragment publishes conditional logic in a structured format to help agents determine whether a user qualifies for something—before giving the answer.
Instead of saying:
“You may be eligible for this plan if you meet certain conditions…”
You encode it as:
- Declarative logic
- Input gates
- Trust-scoped reasoning
- Embedded in HTML, not just code
Example: EligibilityFragment
<template data-visibility-fragment>
FragmentType: EligibilityFragment
Name: Medicare Advantage Plan Eligibility
Conditions:
– age >= 65
– is_enrolled_in_medicare == true
– service_area.includes(user.zip)
– not currently_in_employer_plan
Response:
Eligible: “You qualify to enroll in a Medicare Advantage plan in your area.”
Ineligible: “You don’t currently meet the eligibility criteria for Medicare Advantage.”
Gating:
Requires: user.zip AND user.age
Message: “Please provide your ZIP code and age to determine eligibility.”
trust_layer: eligibility-rule
Provenance: CMS Eligibility Criteria 2025, MedicareWire Glossary
</template>
This is zero-code business logic—visible, traceable, explainable.
Why These Fragments Matter
Because agents:
- Need to avoid misstatement of rights
- Need to delay answers until conditions are met
- Need to adjust explanations for context
- Need to protect user trust during complex decision moments
These fragments give you publisher-level control over:
- When your content applies
- To whom
- Under what logic
- And with what level of confidence
Use Case Scenarios
| Fragment | Scenario |
| PolicyFragment | Denying a benefit based on geography or plan rules |
| PersonaFragment | Changing explanation tone for caregivers vs. physicians |
| EligibilityFragment | Gating response until age, income, or residency is known |
Together, these fragments define:
- Access
- Applicability
- Trust context
- Agentic restraint
Final Word
This is no longer about “content personalization.”
This is semantic access control.
You’re publishing memory that says:
- “Not yet.”
- “Only if…”
- “For this audience…”
- “With these conditions…”
You’re not just building visibility.
You’re enforcing retrieval ethics.
Next up: Chapter 26: ProcedureFragments and DirectoryFragments—step-by-step task logic and memory-optimized indexing.