Jump Through This Page
1. Purpose
The Intake Burden Mapping Card maps the burden imposed on a user, claimant, patient, worker, participant, applicant, or affected node during an intake, reporting, onboarding, appeal, access, or repair process.
It exists because many systems treat intake as neutral.
But intake is not neutral when it requires excessive:
textScroll
disclosure
documentation
repetition
time
format compliance
technical access
emotional labor
cognitive load
risk exposure
privacy exposure
proof production
self-advocacy
navigation laborA system may appear to offer access while quietly making access too costly to use.
IBMC asks:
textScroll
What burden does the intake pathway impose before help, repair, access, or recognition becomes available?The Constructs & Operating Systems Registry identifies Intake Burden Mapping Card as a burden-mapping construct for evaluating intake, reporting, access, appeal, and repair pathways in terms of load placed on the entering or affected node.
2. Core Question
Does the intake pathway allow coherent access to support, repair, recognition, or participation, or does it transfer excessive burden onto the node seeking entry?
Secondary questions:
- What must the node provide before being recognized?
- What must be disclosed?
- What must be documented?
- What must be repeated?
- What time, energy, language, format, or access requirements exist?
- Is support available during intake?
- Does the pathway require capacities the node may lack?
- Does the process expose the node to safety, privacy, retaliation, or legitimacy risk?
- Where do people drop out?
- Does dropout indicate lack of need, or excessive burden?
- Does the intake process restore coherence or export burden?
- Is ∅ more coherent than forcing the current intake pathway?
3. Construct Class
TableScroll
| Field | Value |
|---|---|
| Construct Class | Burden Mapping / Intake Diagnostic |
| Secondary Class | Access / Disclosure / Documentation Load Construct |
| Operating System | No |
| Primary Module | Justice · Governance · Legitimacy / Restoration / Institutional Design |
| Related Modules | Coherence, Economics, AI Governance, Healthcare / Service Systems, Security |
IBMC is a diagnostic construct because it evaluates the load imposed by a pathway before the system provides the thing the pathway promises.
It is a card because it is designed to be usable as a compact assessment object inside larger workflows: VRPS, CSE, CIG, ECF, RIT, and institutional audits.
4. Card Structure
The Intake Burden Mapping Card can be represented as:
textScroll
Entry Node
→ Required Disclosure
→ Required Documentation
→ Required Repetition
→ Access / Format Demands
→ Time / Energy Cost
→ Exposure Risk
→ Support Available
→ Dropout Point
→ Repair / Recognition OutcomeCompressed:
textScroll
IBMC = intake_load - support_available + exposure_risk + recurrence_costThe card asks whether intake load exceeds the node’s available capacity.
If intake load exceeds support, the pathway may become burden-inverting.
5. When to Use
Use the Intake Burden Mapping Card when a system requires a node to enter through a formal or informal intake process.
Use IBMC when:
- someone must apply, report, disclose, appeal, onboard, request access, or seek repair
- users abandon a pathway before completion
- harmed nodes must repeatedly retell harm
- a process requires extensive documentation before recognition
- a patient, applicant, claimant, worker, student, creator, or user faces high administrative load
- an AI or institutional system requires structured input before support
- a platform appeal process is opaque or repetitive
- access depends on format, language, device, literacy, time, or documentation capacity
- support is not available until after high burden is paid
- a repair pathway is underused despite visible need
- intake becomes a gatekeeping layer
- the system confuses low completion with low demand
Do not use IBMC as the primary construct when the central question is:
TableScroll
| If the question is... | Prefer... |
|---|---|
| Can harmed node reach full resolution? | VRPS |
| Is economic value circulating? | ECF |
| Is support adequate under load? | CSE |
| What is the affected node state-space? | Empathy Interface |
| What restorative interaction sequence applies? | RIT |
| Is cognitive infrastructure governed adequately? | CIG |
| Is accountability symmetrical? | ECA |
| What restoration arc applies? | RAM |
IBMC focuses specifically on the intake layer.
6. Derivation
IBMC is derived from a recurring UTS pattern:
textScroll
node needs support / repair / access
+ pathway requires high intake burden
+ node lacks capacity to complete pathway
= access failure disguised as non-participationA second pattern:
textScroll
harm reduces capacity
+ repair requires high documentation and repetition
+ harmed node must prove, explain, and navigate
= burden inversionA third pattern:
textScroll
institution offers formal intake
+ intake filters out high-need nodes
+ institution measures completed cases only
= hidden demand suppressionIBMC exists because the cost of entering a system is part of the system.
Its core distinction is:
textScroll
available pathway is not accessible pathway7. UTS Basis
IBMC assembles the following UTS mechanics.
7.1 State Variables
TableScroll
| Variable | Role in IBMC |
|---|---|
| O | Measures whether intake preserves or degrades coherence. |
| H | Tracks hidden burden: dropout, exhaustion, repeated disclosure, unrecognized need. |
| ε | Tracks uncertainty in requirements, eligibility, documentation, and outcome. |
| ι | Detects inversion where help-seeking becomes further burden. |
| Au | Measures traceability of requirements, pathway status, and decision points. |
| µᵢ | Preserves meaning, dignity, context, and affected-node standing during intake. |
| BΣ | Maintains privacy, consent, role, safety, and information boundaries. |
| K | Tracks compatibility between intake demands and node capacity. |
| R | Measures support and restoration capacity available during intake. |
| Φ | Tracks institutional force, gatekeeping power, dependency, or access pressure. |
7.2 Primary U-Layer Pattern
IBMC most commonly localizes through:
textScroll
U2 → U3 → U4 → U5 → U6Meaning:
textScroll
access boundaries
→ intake execution
→ classification / eligibility
→ timing and burden
→ recognition and legitimacyIntake failures often begin with access boundaries, appear during process execution, become classification or eligibility decisions, compound through time, and affect recognition.
8. Inputs
8.1 Core Observational Inputs
TableScroll
| Input | Description |
|---|---|
| Intake pathway | The process by which a node enters, reports, applies, appeals, requests, or seeks repair. |
| Requesting node | The node attempting to enter or use the pathway. |
| Affected node | The node harmed, burdened, excluded, denied, or needing support. |
| Purpose of intake | What the pathway claims to enable: access, aid, repair, service, classification, escalation, appeal, etc. |
| Required information | What must be provided to begin or continue. |
| Required documentation | Records, forms, proof, evidence, logs, images, signatures, ID, history, or prior decisions. |
| Required repetition | How many times the node must restate, resubmit, or reprove. |
| Time requirement | Duration, deadlines, wait times, scheduling burden, or response latency. |
| Access requirement | Device, internet, location, transportation, login, account, language, literacy, or interface access. |
| Language / format requirement | Required form, terminology, language, category, structure, or evidence format. |
| Privacy exposure | Sensitive information that must be revealed. |
| Safety exposure | Retaliation, contact, visibility, or risk created by using intake. |
| Support availability | Help available during the pathway. |
| Failure / dropout point | Where people abandon or cannot complete the process. |
| Repair pathway | What happens after successful intake. |
8.2 Diagnostic Inputs
TableScroll
| Diagnostic | What It Measures | Why It Matters |
|---|---|---|
| Intake Burden | Total load imposed before access or repair | Core IBMC diagnostic. |
| Disclosure Burden | Amount and sensitivity of required disclosure | High disclosure can block access. |
| Documentation Burden | Proof and record load required | Excessive documentation creates traps. |
| Cognitive Load | Complexity, ambiguity, and navigation burden | High load filters out high-need nodes. |
| Time Cost | Time, waiting, deadlines, and scheduling burden | Time is a real access cost. |
| Access Friction | Device, location, language, account, or interface barriers | Determines real accessibility. |
| Affected Node Cost | Burden on the node needing support or repair | Should not exceed capacity. |
| Power Asymmetry | Difference between institution and entering node | Raises burden threshold. |
| Recognition Integrity | Whether node is recognized before excessive burden | Prevents proof-before-standing failure. |
| Pathway Viability | Whether the intake can realistically be completed | Core output. |
| Boundary Integrity | Privacy, consent, safety, and information boundaries | Prevents exposure. |
| Feedback Integrity | Whether user difficulty changes the pathway | Prevents static gatekeeping. |
| Restoration Capacity | Support available during and after intake | Required for coherence. |
| Dropout Risk | Likelihood node abandons pathway due to load | Hidden demand signal. |
| Recurrence Risk | Whether intake burden repeats across cases | Shows structural failure. |
9. Outputs
IBMC produces burden maps, access-risk assessments, and intake repair decisions.
9.1 Intake Burden Assessment
Possible outputs:
textScroll
Intake burden low
Intake burden proportionate
Intake burden high but supported
Intake burden excessive
Intake burden unsafe
Intake burden inverted
Intake burden pathway-invalidating9.2 Access Assessment
Possible outputs:
textScroll
Access coherent
Access partial
Access fragile
Access format-dependent
Access documentation-dependent
Access support-dependent
Access blocked
Access formally available but practically inaccessible9.3 Recognition Assessment
Possible outputs:
textScroll
Recognition present at entry
Recognition delayed
Recognition conditional on proof
Recognition absent
Recognition lost through format
Recognition requires restoration9.4 Decision Outputs
TableScroll
| Output | Meaning |
|---|---|
| Intake burden coherent | Intake load is proportionate and supported. |
| Reduce intake burden | Overall pathway burden exceeds coherence threshold. |
| Reduce disclosure burden | Required disclosure is excessive or unsafe. |
| Reduce documentation burden | Proof requirements exceed capacity or necessity. |
| Increase support | Support must be available before or during intake. |
| Repair access pathway | Device, language, format, transportation, login, or interface barriers must be reduced. |
| Restore recognition | Standing must not depend on exhausting proof production. |
| Split intake stages | Minimal entry should precede deeper documentation. |
| Pause intake | Continuing current pathway would re-burden or expose the node. |
| Return ∅ | No coherent intake path exists under current structure. |
10. Operating Logic
10.1 Basic Flow
textScroll
1. Identify intake pathway.
2. Identify requesting and affected nodes.
3. Define purpose of intake.
4. Map required information.
5. Map required documentation.
6. Map required repetition.
7. Map time, access, and format requirements.
8. Assess disclosure, privacy, and safety exposure.
9. Assess support availability.
10. Identify failure / dropout points.
11. Assess recognition integrity.
12. Assess pathway viability.
13. Classify burden state.
14. Recommend burden reduction, support, access repair, recognition restoration, staged intake, pause, or ∅.
15. Validate recurrence.10.2 Burden Non-Inversion Rule
textScroll
IF intake requires more capacity than the entering node has,
THEN the pathway is not accessible.
IF the node is seeking repair because capacity was damaged,
THEN intake burden must be reduced or supported.
IF recognition depends on excessive disclosure or proof,
THEN recognition restoration is required.
IF dropout is high,
THEN do not assume low demand; check burden.10.3 Minimal Entry Rule
textScroll
Intake should separate minimal entry from full verification.
Minimum coherent intake should capture enough to:
- recognize the node
- preserve safety
- open a support path
- prevent duplicate burden
- identify urgency
- define next step
Full documentation should not be required before basic recognition where safety and repair are at stake.11. Operators Used
TableScroll
| Operator | Role in IBMC |
|---|---|
| Ξ — Classification | Classifies intake burden, access status, recognition state, and dropout risk. |
| Δ — Differentiation | Separates formal availability from practical accessibility, and documentation from recognition. |
| Μ — Mapping | Maps required disclosures, documents, repetitions, time costs, and failure points. |
| Π — Constraint / Scoping | Limits intake burden to what is necessary and proportionate. |
| Λ — Compatibility | Tests fit between intake requirements and node capacity. |
| ⊗ — Coupling | Evaluates dependency, gatekeeping, and forced recoupling during intake. |
| ℛ — Restoration | Repairs access, recognition, support, and pathway burden. |
| Σ — Integration / Coherence Binding | Integrates access, recognition, documentation, and support into a coherent pathway. |
| Τ — Time Validation | Confirms burden reduction holds across recurrence. |
12. Gates Required
TableScroll
| Gate | Required Condition | Failure Result |
|---|---|---|
| Intake Proportionality Gate | Intake demand is proportional to purpose and node capacity. | Reduce intake burden. |
| Disclosure Safety Gate | Required disclosure does not create unsafe exposure. | Reduce disclosure or protect boundary. |
| Documentation Burden Gate | Documentation demand does not exceed necessity or capacity. | Reduce documentation requirement. |
| BΣ validity | Privacy, consent, access, role, and safety boundaries hold. | Boundary reconstitution required. |
| MS-Gate | Node standing and meaning are recognized at entry. | Recognition restoration required. |
| FI-Gate | Intake difficulty can change the pathway. | Feedback restoration required. |
| R sufficiency | Support or restoration exists during intake. | Increase support before continuing. |
| Access Validity Gate | Pathway can actually be reached and used. | Repair access pathway. |
| Burden Non-Inversion Gate | Intake does not worsen the burden it is meant to resolve. | Split, simplify, support, or pause. |
| Τ validation | Intake repairs hold across repeated cases. | Continue monitoring; do not claim completion. |
13. Failure Modes Detected
TableScroll
| Failure Mode | Detection Signal |
|---|---|
| Intake Burden Inversion | Help-seeking adds more burden than support. |
| Disclosure Overload | Node must reveal too much before safety or recognition. |
| Documentation Trap | Proof requirements block access to repair or service. |
| Access Friction Collapse | Device, location, format, login, language, or interface blocks use. |
| Recognition Failure | Node is not recognized until excessive proof is provided. |
| Pathway Dropout | Nodes abandon process before support due to load. |
| Procedural Gatekeeping | Intake functions as exclusion while appearing neutral. |
| Support Starvation | Node receives no support until after high burden is paid. |
| Privacy Exposure | Intake requires unnecessary sensitive information. |
| Safety Exposure | Intake creates retaliation, visibility, or contact risk. |
| Format Lockout | Required categories or forms exclude valid cases. |
| Time Cost Inflation | Waiting, deadlines, or scheduling burden blocks access. |
| Restoration Lockout | Intake never reaches meaningful repair. |
| Burden Export to Affected Node | Institution shifts navigational burden to the node needing help. |
14. Restoration Links
TableScroll
| Restoration Arc | When Activated |
|---|---|
| Intake Burden Reduction | Intake load exceeds coherence threshold. |
| Access Pathway Restoration | Pathway is formally available but practically inaccessible. |
| Recognition Restoration | Standing is delayed or conditional on excessive burden. |
| Boundary Reconstitution | Privacy, safety, consent, or disclosure boundaries fail. |
| Feedback Restoration | Intake difficulty does not change the system. |
| Slack Regeneration | Entering node lacks capacity to complete pathway. |
| Justice-Aligned Repair | Burden is carried by affected nodes under asymmetry. |
| Pathway Simplification | Steps, forms, repetitions, or requirements must be reduced. |
| Support Provisioning | Assistance must exist before or during intake. |
| Recurrence Reduction | Repeated dropout or burden pattern must be interrupted. |
| Origin-Layer Repair | Intake failure originates in deeper institutional design. |
15. U-Layer Localization
TableScroll
| U-Layer | Relevance |
|---|---|
| U0 — Substrate | Physical location, web infrastructure, forms, devices, records, documents, and system substrate. |
| U1 — Power / Budgets | Staff capacity, support resources, institutional authority, review budget, and user capacity. |
| U2 — Configuration / Boundaries | Access requirements, privacy boundaries, consent, eligibility, scope, and safety limits. |
| U3 — Execution / Runtime | Actual intake experience, forms, calls, uploads, interviews, appointments, or escalation. |
| U4 — Classification / Metrics | Eligibility, severity, category, priority, completeness, and case classification. |
| U5 — Coordination / Time | Deadlines, scheduling, wait times, repetition, response latency, and process duration. |
| U6 — Coherence Field | Recognition, dignity, trust, legitimacy, and willingness to continue. |
| U7 — Memory / Recurrence | Prior submissions, repeated disclosure, duplicated documents, and recurring pathway failure. |
| U8 — Environment / Forcing | Crisis, scarcity, retaliation pressure, legal pressure, institutional load, or external demand. |
IBMC most commonly localizes through:
textScroll
U2 → U3 → U4 → U5 → U6This means intake burden begins in access boundaries, manifests in process execution, becomes classification, compounds through time, and affects recognition and legitimacy.
16. Example Use Case
Scenario
A patient with limited energy needs medical help for a recurring condition.
The clinic requires a long online form, portal login, insurance upload, repeated medical history, appointment scheduling during work hours, and separate phone confirmation. The patient has already provided most of this information before.
The clinic treats the process as normal intake.
IBMC Evaluation
The construct checks:
- required information
- repeated documentation
- time burden
- access friction
- support availability
- recognition integrity
- dropout risk
- repair pathway
Likely Findings
textScroll
Intake burden: high
Documentation burden: repeated
Time cost: high
Access friction: portal-dependent
Recognition: delayed until form completion
Support availability: low
Dropout risk: elevated
Pathway viability: strainedRecommended Output
textScroll
Do not treat repeated form completion as neutral.
Pre-fill known information.
Allow low-burden entry.
Separate urgent triage from full documentation.
Provide support during intake.
Reduce repetition.
Recognize patient standing before full administrative completion.Interpretation
The pathway exists, but its intake burden may prevent coherent access.
IBMC maps the burden before judging participation or compliance.
17. Anti-Patterns
Do not use IBMC to:
- treat formal availability as accessibility
- assume dropout means low demand
- require full proof before basic recognition
- make harmed or burdened nodes repeat themselves unnecessarily
- hide institutional burden inside forms
- treat documentation as neutral
- require high cognitive load before support
- ignore language, device, time, and format barriers
- require unsafe disclosure before safety
- treat self-advocacy as free labor
- measure completed cases while ignoring abandoned attempts
- treat intake as separate from justice or repair
- add automation that increases user burden
- classify non-completion as user failure without burden mapping
18. Completion Criteria
An IBMC assessment is complete when:
- intake pathway is identified
- requesting and affected nodes are identified
- purpose of intake is defined
- required information is mapped
- required documentation is mapped
- required repetition is mapped
- time, access, and format demands are assessed
- disclosure, privacy, and safety exposure are checked
- support availability is evaluated
- dropout / failure points are mapped
- recognition integrity is assessed
- pathway viability is classified
- burden reduction, support increase, access repair, recognition restoration, staged intake, pause, or ∅ is returned
- recurrence validation is defined
19. Machine-Readable Summary
yamlScroll
construct_id: "CONSTRUCT-031"
title: "Intake Burden Mapping Card"
abbreviation: "IBMC"
type: "construct"
status: "draft-integrated"
construct_class: "Burden Mapping / Intake Diagnostic"
operating_system: false
primary_module: "Justice · Governance · Legitimacy / Restoration / Institutional Design"
related_modules:
- "Coherence"
- "Economics"
- "AI Governance"
- "Healthcare / Service Systems"
- "Security"
core_question: "Does the intake pathway allow coherent access to support, repair, recognition, or participation, or does it transfer excessive burden onto the node seeking entry?"
definition: "The Intake Burden Mapping Card maps the burden imposed on a user, claimant, patient, worker, participant, applicant, or affected node during intake, reporting, onboarding, appeal, access, or repair processes."
card_structure: "Entry Node → Required Disclosure → Required Documentation → Required Repetition → Access / Format Demands → Time / Energy Cost → Exposure Risk → Support Available → Dropout Point → Repair / Recognition Outcome"
compressed_form: "IBMC = intake_load - support_available + exposure_risk + recurrence_cost"
inputs:
state_variables:
- "O"
- "H"
- "ε"
- "ι"
- "Au"
- "µᵢ"
- "BΣ"
- "K"
- "R"
- "Φ"
diagnostics:
- "Intake Burden"
- "Disclosure Burden"
- "Documentation Burden"
- "Cognitive Load"
- "Time Cost"
- "Access Friction"
- "Affected Node Cost"
- "Power Asymmetry"
- "Recognition Integrity"
- "Pathway Viability"
- "Boundary Integrity"
- "Feedback Integrity"
- "Restoration Capacity"
- "Dropout Risk"
- "Recurrence Risk"
gates:
- "Intake Proportionality Gate"
- "Disclosure Safety Gate"
- "Documentation Burden Gate"
- "BΣ validity"
- "MS-Gate"
- "FI-Gate"
- "R sufficiency"
- "Access Validity Gate"
- "Burden Non-Inversion Gate"
- "Τ validation"
observations:
- "intake pathway"
- "requesting node"
- "affected node"
- "purpose of intake"
- "required information"
- "required documentation"
- "required repetition"
- "time requirement"
- "access requirement"
- "language / format requirement"
- "privacy exposure"
- "safety exposure"
- "support availability"
- "failure / dropout point"
- "repair pathway"
outputs:
assessments:
- "intake burden status"
- "disclosure burden status"
- "documentation burden status"
- "access friction status"
- "recognition status"
- "burden inversion risk"
- "pathway viability"
- "dropout risk"
- "restoration sufficiency"
- "boundary status"
decisions:
- "intake burden coherent"
- "reduce intake burden"
- "reduce disclosure burden"
- "reduce documentation burden"
- "increase support"
- "repair access pathway"
- "restore recognition"
- "split intake stages"
- "pause intake"
- "return ∅"
maps:
- "intake burden map"
- "disclosure burden map"
- "documentation burden map"
- "access friction map"
- "dropout point map"
- "support requirement map"
- "recognition repair map"
- "restoration pathway map"
- "recurrence map"
dependencies:
operators:
- "Ξ"
- "Δ"
- "Μ"
- "Π"
- "Λ"
- "⊗"
- "ℛ"
- "Σ"
- "Τ"
failure_modes:
- "Intake Burden Inversion"
- "Disclosure Overload"
- "Documentation Trap"
- "Access Friction Collapse"
- "Recognition Failure"
- "Pathway Dropout"
- "Procedural Gatekeeping"
- "Support Starvation"
- "Privacy Exposure"
- "Safety Exposure"
- "Format Lockout"
- "Time Cost Inflation"
- "Restoration Lockout"
- "Burden Export to Affected Node"
restoration_arcs:
- "Intake Burden Reduction"
- "Access Pathway Restoration"
- "Recognition Restoration"
- "Boundary Reconstitution"
- "Feedback Restoration"
- "Slack Regeneration"
- "Justice-Aligned Repair"
- "Pathway Simplification"
- "Support Provisioning"
- "Recurrence Reduction"
- "Origin-Layer Repair"
u_layers:
primary:
- "U1"
- "U2"
- "U3"
- "U4"
- "U5"
- "U6"
secondary:
- "U0"
- "U7"
- "U8"
null_outcome_allowed: true
available_pathway_is_not_accessible_pathway: true
dropout_does_not_equal_low_demand: true20. Citation
Citation ID: construct-intake-burden-mapping-card-v1-0
Recommended citation:
Universal Theory Stack. “CONSTRUCT-031 — Intake Burden Mapping Card.” UTS Constructs Registry, Version 1.0.0, 2026.
21. Summary
The Intake Burden Mapping Card evaluates the load imposed before a system grants access, recognition, support, repair, or participation.
Its core distinction is:
textScroll
available pathway is not accessible pathwayIBMC maps disclosure burden, documentation burden, repetition, time cost, access friction, privacy exposure, safety exposure, support availability, recognition timing, dropout points, and repair outcomes.
Its core logic is:
textScroll
Intake is coherent only when the burden of entry is proportional, supported, safe, and compatible with the node seeking access.When intake becomes gatekeeping, proof exhaustion, repeated disclosure, documentation trap, or burden inversion, IBMC recommends burden reduction, support provisioning, access repair, staged intake, recognition restoration, process pause, or:
textScroll
∅IBMC gives UTS a compact diagnostic card for measuring whether systems are truly accessible or merely formally available.