Constraints
TL;DR
A constraint is a structural quantity you decide to control in the null model. A grand-canonical model matches it in expectation; a microcanonical model fixes it exactly (realization by realization), except for the explicitly documented hybrid strength+cost route. Which combinations are implemented is listed in the generated capability matrix.
The six constraints
STRENGTH
Out and in strengths:
- Grand canonical: expected strengths match the input sequence, \(s_i^{\mathrm{out}}=\sum_j\mathbb E[t_{ij}]\).
- Microcanonical: row and column sums are exact.
STRENGTH_COST
Total pair cost
- Grand canonical: expected cost \(C^\star=\sum_{ij}\mathbb E[t_{ij}]d_{ij}\) is matched; expected strengths are also matched.
- Microcanonical (hybrid): strengths are exact; cost is matched in
expectation through the cost multiplier \(\gamma\) (
f_{ij}=e^{-\gamma d_{ij}}). This route is hybrid, never summarized as "everything exact".
STRENGTH_EDGES
Occupied-pair count:
- Grand canonical: expected strengths and expected \(E\) are matched.
- Microcanonical: strengths and \(E\) are exact.
STRENGTH_DEGREE
Out/in degree sequences:
- Grand canonical: expected strengths and expected degree sequences are matched.
- Microcanonical: strengths and degree sequences are exact.
DEGREE_EVENTS
Degree sequences plus total events:
- Grand canonical: expected degree sequences and expected \(T\) are matched.
- Microcanonical: degree sequences and \(T\) are exact.
EDGES_EVENTS
Occupied-pair count plus total events;
- Grand canonical: expected \(E\) and expected \(T\) are matched; all pair parameters collapse to global multipliers (a global-parameter special case of the generic pair parameterization).
- Microcanonical: \(E\) and \(T\) are exact.
EDGES_EVENTS is one of the six official constraint types exposed by the
capability registry.
The zero-inflated support layer
Constraints that involve \(E\) or the degree sequences condition on whether a pair is occupied; they use a zero-inflated pair law. Define the positive-support partition factor
which evaluates to
With support fugacity \(\ell_{ij}\),
Equivalently, the conditional mean on the positive support is
which does not depend on the support fugacity \(\ell_{ij}\).
The support-aware constraints (STRENGTH_EDGES, STRENGTH_DEGREE,
DEGREE_EVENTS, EDGES_EVENTS) use this layer; STRENGTH and
STRENGTH_COST are non-zero-inflated.
High-level constraint table
| Constraint | Symbolic quantities | GC semantics | Canonical semantics | MC semantics |
|---|---|---|---|---|
| Strength | \(s^{out},s^{in}\) | expected | registry-derived | exact |
| Strength + cost | \(s,C\) | expected | registry-derived | strengths exact; cost expected |
| Strength + edges | \(s,E\) | expected | registry-derived | exact |
| Strength + degree | \(s,k\) | expected | registry-derived | exact |
| Degree + events | \(k,T\) | expected | registry-derived | exact |
| Edges + events | \(E,T\) | expected | registry-derived | exact |
The "registry-derived" canonical cells reflect the current capability registry; see the generated capability matrix for what is actually implemented.
Feasibility
Necessary relations for any feasible non-binary network:
For positive-support edges (every occupied pair contributes at least one event):
For B under fixed degree, each occupied pair holds at most \(M\) events:
For fixed \((E,T)\):
Add domain bounds: no self loops requires \(k_i\le N-1\); with self loops \(k_i\le N\); the strength budget must fit the admissible pair domain.
Necessary, not sufficient
These are necessary conditions. Some sparse-domain problems require additional feasibility conditions; simple scalar checks do not prove every sparse constrained instance feasible. In practice, derive constraints from a valid witness network as the documenting examples do.
Fixed / known pairs
Fixed pairs are not a separate constraint enum. They transform the problem to a residual domain after subtracting the fixed contributions (see Fixed / known pairs).