Missing observations and evaluated false conditions need different next steps. I built a small synthetic summary function to keep them from disappearing into one waiting label. It connects no real data source or external system.
Give each rule an availability axis and a condition axis
summarize_rules accepts rule records with exactly id, required, available and met. Availability is the caller's declaration that the observations needed for evaluation are prepared. Met is the condition result derived from those observations. An observed false condition and a condition that could not be evaluated must not be compressed into one interchangeable false value.
The function does not read observations or establish their truth. The integrating program owns the evidence behind an availability declaration. The word evidence in this example does not create source authentication or freshness checks. Its responsibility is limited to summarizing two explicitly different states without losing the distinction needed for explanation.
A later native repair reproduced a null long-term average becoming zero upstream and therefore being declared available. This summary cannot compare a caller’s incorrect availability declaration with the source quote and repair it. The caller must check source types, units, timing and permitted conversions before constructing availability. Neither this implementation nor its ZIP was automatically installed in the native product.
The next connected market-input test found array price [100] and boolean price true becoming numeric 100 and 1 before reaching the engine check. The native repair connected one numeric interpreter through the payload, snapshot and engine. This summary performs no such conversion. If available=True and met=True satisfy its input format, it cannot discover malformed source observations behind them; the caller must verify the transformations before declaring availability.
Keep an unavailable condition unknown
When available is true, met must be an actual boolean. When available is false, met must be None. A claim that unavailable observations already satisfied a condition is rejected, as is representing an unevaluated condition as an ordinary false result. Strings and numeric zero are not coerced into boolean declarations to make malformed input look like a valid waiting state.
Rule identifiers are unique lowercase identifiers and a list contains one to sixty-four records. Extra raw fields and omitted fields are errors. These are the public example's boundaries, not a claim about the number of rules every business needs. Larger systems must establish their own grouping and identity scope before extending the implementation and tests.
Count required rules separately from optional observations
Required declares whether a rule participates in the summary's mandatory conditions. An unavailable optional observation must not erase the fact that required inputs are prepared. Conversely, several matching optional observations cannot hide one missing mandatory input. An entirely optional list is rejected rather than allowing a vacuous all-passed result with no required population.
The required_total, available_required and met_required counts all use that same required population. Missing optional observations have their own list. This is an explicit policy chosen for the independent example, not a copy of a special rule-name exception in the original program. It does not automatically replace that program's policy or infer which business rules ought to be mandatory.
Explore the implementation
Complete independent synthetic implementation
"""Independent declared rule summary. No data source, strategy or action."""
import re
def summarize_rules(rows):
if type(rows) is not list or not 1<=len(rows)<=64:raise ValueError('RULE_LIST_REQUIRED')
seen=set();required=[];optional=[]
for row in rows:
if type(row) is not dict or set(row)!={'id','required','available','met'}:raise ValueError('EXACT_RULE_FIELDS')
if type(row['id']) is not str or not re.fullmatch(r'[a-z][a-z0-9_-]{0,39}',row['id']):raise ValueError('RULE_ID')
if row['id'] in seen:raise ValueError('DUPLICATE_RULE_ID')
seen.add(row['id'])
if type(row['required']) is not bool or type(row['available']) is not bool:raise ValueError('BOOLEAN_FLAGS')
if row['available']:
if type(row['met']) is not bool:raise ValueError('OBSERVED_CONDITION_REQUIRED')
elif row['met'] is not None:raise ValueError('UNAVAILABLE_CONDITION_MUST_BE_UNKNOWN')
(required if row['required'] else optional).append(row)
if not required:raise ValueError('REQUIRED_RULE_NEEDED')
missing=sorted(r['id'] for r in required if not r['available'])
unmet=sorted(r['id'] for r in required if r['available'] and not r['met'])
return {'state':'inputs_missing' if missing else 'conditions_unmet' if unmet else 'conditions_met',
'required_total':len(required),'available_required':sum(r['available'] for r in required),
'met_required':sum(r['available'] and r['met'] for r in required),
'missing_required':missing,'unmet_required':unmet,
'missing_optional':sorted(r['id'] for r in optional if not r['available']),
'evaluation_ready':not missing,'all_required_conditions_met':not missing and not unmet,
'executes_action':False,'authenticates_evidence':False}
Choose a headline state without discarding other reasons
Missing required inputs produce inputs_missing. Complete inputs with at least one observed false required condition produce conditions_unmet. When all required conditions are true the state is conditions_met. Missing input has headline priority, yet already evaluated false conditions remain in unmet_required. Choosing one headline does not require throwing away the other observations.
Evaluation_ready expresses only that the caller declared every required input available. It can remain true when a condition is false. All_required_conditions_met combines availability with required condition results. Consumers can therefore distinguish being able to evaluate from satisfying the evaluated conditions. Reason lists are sorted so reordering equivalent input records does not change the summary.
A matched condition does not execute an action
Executes_action and authenticates_evidence remain false in every valid result. Even complete required conditions do not connect to real input, persistence, orders or approval. The module calculates no quantities, amounts or strategy signals. Any subsequent action belongs to a separate layer that checks authority and the current operation state rather than treating this summary as permission.
Twenty-two independent tests ran in the source directory and again after ZIP extraction. Five saved records illustrate missing input, observed false, all required conditions met, unavailable optional material and mixed reasons. The selector below reads those synthetic outputs without receiving visitor material. DOM-stub checks are reported separately from an actual browser or original-program inspection.
Connect the summary to another program’s wording
The ZIP contains the independent implementation, tests, example runner and actual synthetic execution records. Run python -B -m unittest -v from the extracted directory. Modification, redistribution and commercial reuse are permitted without warranty. This newly authored teaching contract contains neither an extracted customer program nor its operational material.
Before integration, decide which observations are required, where availability evidence originates and how the interface should explain unknown versus evaluated false. Those states lead an operator toward different next steps. Actual data acquisition, freshness checks, permissions, historical persistence and automatic execution remain outside this function and need their own contracts and verification.
Connecting the models requires an explicit representation mapping. The native engine records available:false with met:false for a missing observation, while this Python module requires met=None for an unknown result. No adapter or automatic integration has been implemented. This revision re-extracts the public ZIP for twenty-two synthetic tests and checks its saved-record selector with DOM stubs. The first native follow-up’s twenty-two tests and restored sixteen/twenty-two, and the next input-path repair’s thirty tests and restored twenty-two/thirty, remain separate development records. They are not added to this module’s test count or described as actual browser verification.