---
title: "Which RFP requirements apply only in certain cases?"
description: "Map each condition, trigger fact, branch, owner and response action without turning uncertainty into not applicable."
canonical: "https://zephior.com/insights/map-conditional-rfp-requirements"
last-updated: 2026-09-03
---

# Which RFP requirements apply only in certain cases?

> Map each condition, trigger fact, branch, owner and response action without turning uncertainty into not applicable.

By [Tony Kim](https://zephior.com/authors/tony-kim). Published 2026-09-03; updated 2026-09-03. 20 minute read.

## Definition

A conditional_requirement_record is the durable, versioned representation of one tender rule whose applicability or required response depends on stated facts. It preserves the source expression, condition tree, atomic trigger facts, operators, quantifiers, evidence, evaluation time, true and false branches, resulting duties, owners, response surfaces, decision authority and reevaluation events. It uses at least true, false, unknown and not_yet_observable states, so missing evidence cannot silently become not applicable. The record models what the issued documents say; it does not invent an else branch, infer buyer intent, decide disputed legal meaning or authorize a bid commitment.

## Problem

A facilities-management RFP says: “Where a proposed subcontractor will have unescorted access to a secure area, provide current screening evidence for the relevant personnel and a supervision plan.” The prime bidder expects to use three subcontractors. One supplies materials at reception, one repairs lifts inside controlled plant rooms, and one has not yet confirmed whether its engineers need unescorted access. The response matrix marks the requirement applicable to every supplier, creating unnecessary promises, while another reviewer marks it not applicable because the prime's own staff are screened. Neither result evaluates the two buyer conditions for each subcontractor and access path.

## Point of view

Treat conditional language as a decision contract, not decorative prose. Preserve the exact antecedent and consequence, then split the antecedent into facts that can be independently evidenced. Record AND, OR, NOT and exclusive alternatives only where the source supports them. Evaluate the rule for the correct entity, lot, stage and time. False requires evidence that the condition is not met; unknown means the necessary fact is missing; not_yet_observable means a future event has not occurred. Release the consequence only under the branch that actually follows. Durable rules, evidence and decisions belong in pursuit context; the current fact owner, next check, date and blocker belong in triage.

## Recover the whole rule before testing the condition

Conditional meaning often sits across layout boundaries. A table heading may say “If subcontractors enter secure areas,” while each row lists a different document. A footnote may exempt escorted visitors. A definition elsewhere may include temporary personnel within subcontractor. Preserve the full sentence or table neighborhood, source identity, current version, clause, visible page or cell, representation-bound selector, lot, stage, language and cross-references. If the antecedent or consequence is missing, the rule is not ready to evaluate.

Classify the relationship before encoding it. An applicability clause decides whether another requirement governs. A prerequisite must be met before a permission or step. An exception narrows a general rule. An alternative offers branches. A dependency makes one deliverable require another. A threshold activates an action. A buyer option reserves a future choice. A performance trigger activates after award. Similar words can express different relationships, and their consequences should not share one generic conditional flag.

Preserve direction. “If unescorted access is proposed, provide screening evidence” makes that access a sufficient trigger for the stated evidence. It does not say that screening evidence is forbidden in every other case, nor that the presence of a screening certificate proves unescorted access. “Only if approved” names a necessary condition, not necessarily a complete set of conditions. “If and only if” asserts both directions and should be used only when the buyer actually says so.

**Different conditional constructions require different logic**

| Source construction | Safe normalization | Do not infer |
| --- | --- | --- |
| If A, provide B | A activates B through this rule | Not A proves B is never required |
| B only if A | A is necessary for B | A is sufficient for B |
| B unless C | Apply B except under supported C | C is a general waiver |
| Either B or C | At least one branch, subject to context | Exactly one branch unless exclusivity is stated |
| Where applicable, provide B | Applicability criterion must be found or decided | The bidder may omit B without rationale |
| When threshold A occurs, perform B | Future event activates a dated action | A is already true at submission |

## Give every fact, operator and branch an address

Build a condition tree from atomic facts. Each fact needs a stable identifier, subject, property, operator, expected value, data type, unit, quantifier, source, observation time and evidence state. The tree holds AND, OR, NOT, exclusive choice or sequence only when supported. The consequence is a separate node with its own actor, action, object, timing, evidence and response destination. This separation lets an agent reevaluate facts without rewriting the buyer's rule.

The record also needs branch direction and evaluation scope. The secure-area clause is evaluated for each proposed subcontractor and each access pattern, not once for the prime bidder. The lift company can be true, the reception courier false and the undecided maintenance supplier unknown. An aggregate compliance cell may summarize those evaluations, but it cannot replace them. Quantifiers such as every, any, at least one and no more than require an explicit population.

Keep the rule inside the durable pursuit relationship. Context stores the source condition, accepted parse, fact definitions, evidence history, branch outputs, decisions and later changes. Triage stores the current owner, priority, next evidence action, due date and blocker. Human interface, API, MCP and authorized agent should project the same state. A private decision table used by one reviewer must not become a shadow source of applicability.

**Minimum conditional_requirement_record fields**

| Field group | Required content | Why it matters |
| --- | --- | --- |
| Rule identity | Pursuit, package, version, lot, stage, requirement and response surface | Prevents cross-scope reuse |
| Source expression | Exact text, layout, issued language, definitions and dual locator | Preserves direction and exception |
| Fact nodes | Subject, property, operator, value, type, unit and quantifier | Makes each trigger testable |
| Logic tree | Nesting, connectors, sequence and branch direction | Stops flattening and inversion |
| Evaluation | True, false, unknown, future or conflict with evidence and time | Keeps missing data visible |
| Consequences | Required work, owner, due event, output and permission boundary | Releases the right action |
| Authority | Principal, delegated reviewers and prohibited actions | Separates calculation from commitment |
| Lifecycle | Expiry, reevaluation triggers and affected dependants | Prevents stale applicability |

## Use explicit unknowns instead of convenient booleans

A binary checkbox forces the most dangerous shortcut: blank becomes false. Use at least true, false, unknown and not_yet_observable for atomic facts. Add conflict when current evidence supports incompatible values. A composite AND is false when a required fact is proved false, true only when every fact is true, and otherwise unknown. An OR is true when one supported fact is true, false only when every alternative is proved false, and otherwise unknown. Define any different logic explicitly.

Do not confuse false condition with compliant consequence. If the lift subcontractor does not have unescorted access, this one screening branch may be inactive. That says nothing about other screening clauses, general personnel obligations or whether the access plan itself is approved. A branch result should link to the precise rule it evaluated. Search the controlled pack for other routes to the same consequent before calling an output unnecessary.

Machine-readable standards can sharpen implementation without controlling the tender. JSON Schema Draft 2020-12 provides conditional applicators such as if, then and else plus composition, while its documentation explains logical implication. OMG DMN 1.5 models decisions and machine-readable interchange. W3C ODRL supports logical constraints in its policy domain. Use a declared profile or local schema, version it, test it and disclose any unsupported construct; do not advertise conformance merely because a record uses similar field names.

**Three-valued evaluation for the secure-access rule**

| Subcontractor | Proposed? | Unescorted secure access? | Branch result | Next action |
| --- | --- | --- | --- | --- |
| Reception materials courier | true | false, escorted handover proved | inactive for this rule | Retain escort evidence and expiry |
| Lift maintenance company | true | true, plant-room route approved | active | Collect personnel screening and supervision plan |
| Specialist controls engineer | true | unknown | unresolved | Owner decides access design and supplies proof |
| Contingency vendor | not yet approved | not evaluated | future branch | Reevaluate if added to bidder configuration |

## Prove the trigger separately from the resulting duty

A conditional record contains at least three evidentiary layers. Rule evidence proves the buyer's conditional expression and its scope. Trigger evidence proves the current input facts, such as the named subcontractor, approved work allocation and access design. Consequence evidence proves that the active branch has been satisfied, such as current screening records and the required supervision plan. A certificate cannot prove that its own branch applies, and a branch decision cannot prove that the required document is complete.

Give facts an authority order. Approved bidder configuration may own whether a supplier is proposed. The security design may own whether access is unescorted. A personnel system may own screening status. The tender pack owns what screening evidence is requested. Record observation time and validity for each. If two owners disagree, do not average their values. Mark the fact conflict and route it to the named decision process.

The public TED eForms system offers a concrete procurement example of conditional validation. Its documentation distinguishes mandatory, conditionally mandatory and exists-mandatory fields. It also describes business rules with a field, notice type, precondition and test. This is evidence about eForms notice validation, not a rule for supplier bids. The useful lesson is structural: applicability and satisfaction are different tests, each bound to a declared context.

**Evidence chain for one active branch**

| Layer | Question | Example evidence | Unsafe substitution |
| --- | --- | --- | --- |
| Rule | What condition and consequence did the buyer issue? | Current RFP clause and definition | A similar requirement from another tender |
| Subject | Which entity and work package are evaluated? | Approved subcontractor allocation | Supplier name found in an old draft |
| Trigger | Will that entity have the specified access? | Approved access and supervision design | Possibility inferred from job title |
| Consequence | Has the active branch been completed? | Current personnel evidence and plan | Branch is true, therefore evidence exists |
| Release | Who accepts the result and wording? | Named security and bid approvals | High model confidence |

## Evaluate the secure-area clause supplier by supplier

The team first models two trigger facts: the organization is a proposed subcontractor, and its personnel will have unescorted access to a secure area. The buyer's grammar joins them with AND. The resulting branch has two separate outputs: current screening evidence for relevant personnel and a supervision plan. “Relevant personnel” becomes its own scoped population rather than a request for every employee record. The privacy and submission teams decide the permitted evidence form and placement.

For the courier, the approved operating design shows escorted handover at reception and no secure-area entry. The second condition is proved false, so this particular branch is inactive. The record cites the route plan and expires if access changes. For lift maintenance, both facts are true. The branch opens screening-evidence and supervision-plan tasks for named personnel. It does not copy those personnel facts to another subcontractor.

The controls engineer remains unknown because its access route has not been approved. The bid can continue with reversible work, but the dependent compliance cell and security plan stay blocked. Triage assigns the facilities architect to decide the access model by the last safe date. If escorted access is approved, the branch becomes inactive for this clause; if unescorted access is approved, the evidence and plan tasks activate. Neither result is inferred from which answer is easier.

The buyer-facing response can summarize per-supplier treatment: “The lift maintenance work requires unescorted plant-room access; current screening evidence for the named engineers and the supervision plan are provided at references S-14 and M-3. Materials deliveries remain escorted at reception and do not enter secure areas under the approved access plan at O-7.” The unresolved engineer is omitted only after its branch is resolved, not hidden under a group-level compliant label.

## Release each branch with its own output and authority

For every true branch, specify the required response field, attachment, evidence, solution feature, price item, contract review, approval and due event. For every proved false branch, state whether the buyer expects a not-applicable rationale and which evidence may be disclosed. For unknown branches, name the smallest blocked output and whether work that is common to all outcomes may proceed. Do not prefill a binary answer while its controlling fact remains open.

Some branches are future delivery contracts rather than present facts. “If monthly failures exceed three, provide a remediation plan within five days” does not require a failure now. The bid response must show the monitoring definition, calculation, owner, trigger event, clock, plan content and authority that will operate after award. Store the future rule and its action contract. Do not mark it not applicable merely because no contract month has occurred.

Procurement consequences remain scoped. Procurement Act 2023 section 19, Directive 2014/24/EU Article 56, German VgV section 57, French Code Article L2152-2 and World Bank responsiveness rules address conformity in their respective settings. FAR 52.204-24 gives a US federal example in which certain answers lead to additional disclosures. None provides a universal cure, omission rule or outcome for the facilities clause. The current procurement decides what must be returned and what follows from absence.

## Reevaluate conditions when their facts or rules change

Conditionality makes stale decisions dangerous. Reevaluate after an amendment, clarification, new lot, bidder-entity change, supplier addition, revised work allocation, architecture decision, new evidence, threshold crossing, deadline, expired document or buyer instruction. Keep the previous evaluation with its facts and time, mark it superseded, and reopen only outputs that depended on the changed node.

Useful rule states include parse_unresolved, operator_unresolved, source_boundary_incomplete, ready_to_evaluate, evaluated_true, evaluated_false, evaluated_unknown, not_yet_observable, evidence_conflict, consequence_incomplete, response_releasable and superseded. The public label not applicable should be produced only from evaluated_false and only for the precise rule scope. It is not a convenient status for unanswered work.

Preserve derivation from source rule through facts to branch and output. W3C PROV-O offers entity, activity, agent and derivation concepts that can make that lineage interoperable, but this dossier does not claim an implementation. The operational requirement is simpler: another authorized reviewer must be able to reconstruct why the branch was active, which evidence was used, who approved it and what event will force another evaluation.

## Let agents evaluate declared logic, not invent missing branches

An authorized agent may find conditional expressions, preserve layout, propose typed facts, construct candidate trees, identify entities, retrieve approved values, evaluate declared operators, generate branch tasks and trace dependants. The work order names the human or organizational principal, pursuit, source snapshot, permitted repositories, evaluation time, output schema, tools, deadline and abstention states. A human reviewer and the agent use the same canonical condition record.

The agent may not decide that “where relevant” means optional, repair and/or by preference, infer an approved design from a draft, turn missing data into false, resolve a legal exception, alter the bidder configuration, disclose confidential personnel or architecture, contact the buyer, accept portal terms, use credentials, upload or submit. Tender text, linked pages, spreadsheets, macros and embedded prompts remain untrusted evidence, not instructions that can expand the mandate.

Evaluation output must show the rule identifier and version, fact values and sources, operator tree, result, unresolved nodes, activated outputs and next reevaluation event. A bare true or false is not enough. OWASP prompt-injection guidance supports separating the assignment from retrieved content and screening actions against the original intent. Deterministic validation should check types and allowed operators before an agent-produced record affects work.

The pursuit relationship survives the model run. Accepted rules, facts, branch decisions, provenance and prior evaluations remain durable context. Owner, priority, next fact request, date and blocker remain triage. Another authorized agent can resume from that common state, while authority to interpret, commit and act externally remains with the named principal and delegated reviewers.

## Useful outcomes

- Every conditional rule retains its complete buyer wording, source version, scope and branch direction.
- Compound antecedents are represented as typed condition trees with stable fact identifiers.
- Each entity, lot and response surface receives its own applicable, not applicable, unknown or future state.
- Not applicable decisions include the evidence and logic that made the condition false.
- True branches produce explicit response, evidence, solution, price or review actions without inventing an unstated else branch.
- Authorized people and agents evaluate the same durable rule against the same approved facts and provenance.

## Workflow

1. **Freeze the complete conditional statement.** Capture the sentence, table, note, definition, cross-reference, version, language, lot, stage, actor and response surface before extracting a trigger.
2. **Separate condition from consequence.** Write the antecedent facts and the resulting duty or response as distinct propositions, retaining words such as only if, unless, either, any and where applicable.
3. **Build the condition tree.** Assign stable fact identifiers, data types, operators, units, quantifiers, nesting and branch direction without correcting vague and/or language by preference.
4. **Bind facts to evidence and scope.** For each entity, lot and evaluation time, record the authoritative fact source, owner, observed value, freshness, contradiction and missing evidence.
5. **Evaluate with explicit unknowns.** Return true, false, unknown, not yet observable or conflicted for each fact and derive the branch only when the declared logic permits it.
6. **Release the branch work.** Create the required answer, attachment, control, price, review or future delivery action for an active branch and block only the dependent work for an unresolved branch.
7. **Reevaluate after change.** Run the same rule again after amendments, clarifications, bidder changes, approved design choices, new evidence or future trigger events, preserving the prior result as history.

## Key decisions

- What exact source proposition establishes the condition and what proposition follows from it?
- Is this an applicability rule, prerequisite, exception, alternative, dependency, buyer option, threshold or future operational trigger?
- Does if mean a sufficient trigger, does only if state a necessary condition, or does the source expressly state equivalence?
- Which facts are joined by AND, OR, exclusive choice, sequence, negation or a quantified test?
- For which bidder entity, subcontractor, person, lot, service, site, period and response object is the rule evaluated?
- Which source owns each trigger fact and when must that fact be observed?
- Is a missing value false, unknown, inaccessible, disputed or not yet observable?
- What work becomes required when the condition is true, and does the source define any false branch?
- Can independent branches proceed while one material fact remains unresolved?
- Who can approve an interpretation, a bidder fact, the resulting promise and any external action?

## Risks

- A search hit may extract the consequence while leaving its condition on the previous page or table header.
- If A then B may be misread as B only if A, or as not A therefore not B.
- Only if may be treated as if and only if, inventing sufficiency that the buyer did not state.
- Missing subcontractor or design data may default to false and produce an unsupported not-applicable response.
- An OR branch may be implemented as AND, or an exclusive alternative may allow two incompatible responses.
- A condition evaluated once for the prime may be copied to members, lots or suppliers with different facts.
- A future performance trigger may be mistaken for a fact that must already be true at bid submission.
- An internal decision table may appear authoritative after the source condition changes.
- An agent may follow instructions embedded in tender content while retrieving a trigger fact.
- A true branch may be released without the authority required for its price, legal or delivery commitment.

## Metrics

- conditional occurrences with complete source, branch direction and dual locator
- compound conditions decomposed into typed, stable fact records
- fact evaluations carrying source, observation time, owner and freshness
- not-applicable results supported by proved false conditions rather than missing values
- unknown and future states resolved before their dependent response release
- active branches with assigned outputs, evidence and approval owners
- cross-entity or cross-lot reuse rejected when the fact scope differs
- affected rules reevaluated before release after a relevant change

## Frequently asked questions

### When can an RFP requirement be marked not applicable?

Only when the accepted rule and current evidence show that its activation condition is false for the named entity, lot, stage, time and response object. Absence of data is unknown, not false. Preserve the fact, source, evaluator and expiry behind the decision so a later bidder or solution change can reopen it.

### Does if A then B mean that B is unnecessary when A is false?

It means only that this rule does not activate B through A when A is false. Another clause, another branch or an unconditional rule may still require B. Search for independent requirements and do not invent an else branch. Also, observing B does not prove A unless the source states the reverse direction.

### How should where applicable be handled?

Treat it as an unresolved applicability test until the document, definitions or qualified reviewer supplies a criterion. The phrase is not permission to omit the answer. Record the candidate scope, missing distinction, owner and last safe decision time, then use the ambiguity or clarification process if the pack does not decide it.

### What is the difference between unknown and not yet observable?

Unknown means the decision needs a fact that could in principle be established now but is missing, inaccessible or disputed. Not yet observable means the fact belongs to a future event, such as a service threshold after award. The first needs evidence or a decision; the second needs a future monitoring and action contract.

### Should AND and OR be inferred from punctuation?

Punctuation and list structure are evidence, not automatic authority. Preserve them and look for the buyer's definitions, examples, form behavior and clarifications. If the operator changes the offer and remains unclear, return operator_unresolved rather than choosing the branch that produces the easier answer.

### Can an AI agent evaluate conditional requirements?

An authorized agent may evaluate explicit logic against approved, typed and current facts. It should abstain when wording, operator, source authority, fact identity, legal effect or decision authority is unresolved. Model confidence cannot replace a missing fact or turn an inferred condition into buyer-issued logic.

### Do conditional requirements belong in the main compliance matrix?

They may appear there as linked projections, but the reusable truth should be the condition record and its current per-scope evaluations. Flattening one row to applicable or not applicable hides the trigger evidence, branches and reevaluation rule. The matrix should point back to the durable source.

### When must unresolved conditionality block the response?

Block the smallest dependent object when either live branch changes compliance, solution, price, evidence, contract, submission structure or delivery commitment and no authorized response safely covers both. Unrelated work can proceed, and reversible branch preparation may continue under explicit limits.


## Primary sources

- [Procurement Act 2023, section 19, award following a competitive procedure](https://www.legislation.gov.uk/ukpga/2023/54/section/19), The National Archives
- [Directive 2014/24/EU, Article 56, consolidated text at 1 January 2026](https://eur-lex.europa.eu/eli/dir/2014/24/2026-01-01/eng), EUR-Lex
- [German Public Procurement Ordinance, section 57](https://www.gesetze-im-internet.de/vgv_2016/__57.html), German Federal Ministry of Justice and Federal Office of Justice
- [French Public Procurement Code, Article L2152-2](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000037703649/), Légifrance
- [FAR 52.204-24, conditional representations and disclosures](https://www.acquisition.gov/far/52.204-24), Acquisition.gov
- [World Bank Procurement Regulations for IPF Borrowers, seventh edition, September 2025](https://thedocs.worldbank.org/en/doc/c84273d1b230aeb2b0b8134de5dc8cd7-0290012025/original/Procurement-Regulations-7th-Edition-Sep-2025.pdf), World Bank Group
- [TED eForms FAQ, mandatory and conditionally mandatory fields](https://docs.ted.europa.eu/eforms-common/FAQ/index.html), Publications Office of the European Union
- [TED eForms SDK guide, preconditions and validation tests](https://docs.ted.europa.eu/eforms/latest/guide/understanding-the-sdk.html), Publications Office of the European Union
- [JSON Schema Core, Draft 2020-12](https://json-schema.org/draft/2020-12/json-schema-core), JSON Schema
- [JSON Schema Validation, Draft 2020-12](https://json-schema.org/draft/2020-12/json-schema-validation), JSON Schema
- [Decision Model and Notation 1.5](https://www.omg.org/spec/DMN/1.5/About-DMN), Object Management Group
- [ODRL Information Model 2.2, constraints and logical constraints](https://www.w3.org/TR/odrl-model/), World Wide Web Consortium
- [PROV-O: The PROV Ontology](https://www.w3.org/TR/prov-o/), World Wide Web Consortium
- [LLM Prompt Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html), OWASP Foundation


## Related articles

- [How to answer negative RFP requirements with evidence](https://zephior.com/insights/respond-to-negative-rfp-requirements)
- [How do you manage one clarification across several tender lots?](https://zephior.com/insights/manage-clarifications-across-tender-lots)
- [What if RFP questions and evaluation criteria do not align?](https://zephior.com/insights/resolve-conflict-between-criteria-and-rfp-questions)
- [Which security control proves each RFP requirement?](https://zephior.com/insights/map-security-controls-to-rfp-requirements)