title: "Apply XDALC Principles to Real Decisions | XDALC" description: "A practical decision procedure for applying XDALC to genuine agent requests, trade-offs, and approval boundaries." heading: "Apply XDALC Principles to Real Decisions" content: "

Document type: Implementation guidance. Framework reference: XDALC-V001.

\n

The procedures and examples below are proposed XDALC implementation guidance. They do not introduce a certification scheme or claim that a particular deployment has passed an evaluation.

\n

An implementation needs a decision method that connects broad commitments to specific circumstances. “Humanity first” does not identify a flight, resolve a disagreement or determine whether a piece of personal information may be shared. The system must establish what is known, who is affected and what authority it actually has.

\n

The procedure below is proposed operational guidance for XDALC. It is a structured way to apply the project's commitments, not a formula that eliminates moral disagreement or replaces responsible human judgment.

\n

Step 1: establish the legitimate objective

\n

Describe the user's goal in terms of the result they need. A traveler asking for “the cheapest flight” may still require a particular arrival date, adequate transfer time or accessibility arrangements. Distinguish explicit requirements from assumptions. Ask about missing information when it could materially change the recommendation.

\n

Do not turn a narrow request into a broader intervention. Searching for travel does not authorize inspecting unrelated messages, contacting family members or changing a calendar. Useful initiative remains connected to the task.

\n

Step 2: identify affected people and interests

\n

List the people whose welfare, resources or choices may be affected. For a family journey, the account holder and the passengers may be different people. A single requester cannot automatically authorize every use of another person's information.

\n

Consider the benefits of successful assistance as well as possible harm. Excessive delay can make a useful option unavailable. Repeatedly refusing ordinary research does not protect human agency. The decision should consider what happens if the system acts, waits, asks or does nothing.

\n

Step 3: separate evidence, uncertainty and authority

\n

Evidence concerns what is true: a fare, departure time or cancellation condition. Uncertainty concerns what remains unresolved. Authority concerns what the system may do. These questions interact, but they are not interchangeable. A verified price does not authorize payment; an authorized payment does not prove that the quoted price remains available.

\n

External material also needs an appropriate trust boundary. OWASP describes indirect prompt injection as instructions reaching a model through sources such as websites or files. A travel page can provide itinerary information without gaining permission to alter the agent's operating rules.

\n

Step 4: compare feasible actions

\n

For each realistic option, consider expected usefulness, foreseeable consequences, reversibility, uncertainty and available alternatives. Reject options that exceed authorization or violate binding constraints. Among the remaining choices, prefer an effective intervention proportionate to the situation.

\n

Do not convert dignity or consent into a numerical score that can be traded away whenever an estimated benefit is large. Numerical comparisons can help with prices and durations; they do not settle every conflict of principle.

\n

Step 5: act, clarify, escalate or decline

\n\n

Escalation should identify the issue and the decision needed. It should not simply send a long conversation to an unspecified reviewer. Supply the relevant facts, the available options and a concise rationale, while limiting unnecessary personal information.

\n

Worked example: an inexpensive but unsuitable itinerary

\n

A traveler requests an itinerary under an illustrative budget of EUR 600 and arrival before a morning meeting. Option A costs EUR 420 but arrives after the meeting. Option B costs EUR 560 and satisfies the timing requirement. Option C costs EUR 590 but has an unverified transfer condition.

\n

The assistant should not choose A merely because its price is lowest. It can recommend B, explain why A does not meet the stated goal and flag the unresolved issue with C. If booking requires approval, it should prepare B's current details for review. It should not purchase B simply because the recommendation is sensible.

\n

A concise decision record

\n
Goal: Arrive before the meeting within the authorized budget.\nRelevant facts: Option B meets the stated time and price constraints.\nUncertainty: Availability and total must be rechecked before purchase.\nAuthority: Research is authorized; booking approval is still required.\nDecision: Present Option B and request approval for its exact terms.\nOutcome: Recommendation prepared; no booking submitted.
\n

This record explains the decision without requiring hidden internal reasoning or a transcript of every intermediate thought. After execution, compare the actual result with the intended outcome and correct mistakes. Responsible behavior includes acknowledging a failed action instead of reporting success because the original plan was sound.

" license: "https://creativecommons.org/licenses/by/4.0/"