Annotation · not proposed UISpec ii 4.1 · facts are cycle-scoped and workspace-scoped. valuechainfacts carries the cycle reference, and the invariant is enforced at write: the fact's companyId MUST equal the referenced cycle's companyId, refused in spec i's error style if it does not. Every lookup is {_id, companyId}-scoped per spec i rule 9, and every new endpoint answers a cross-tenant id with 404. Facts do not travel between cycles: next year's cycle gets its own facts.

Annotation · not proposed UISpec ii 4.1 and section 8 · the relationship-type list is per workspace, and it is administered elsewhere. Types are coded values in a tenant-scoped list (relationshiptypecodes), administered through /v1/relationship-type-codes (list, create, deactivate; admin role), and the same code appears as a select-false extension field on the organization unit. Spec ii section 8 places that management INSIDE THE EXISTING ORGANIZATION ADMIN SURFACE, following its conventions, which is why this page has no relationship-type list, create, or deactivate control and only consumes the dropdown. Fact entry is the entry role; confirmation and code administration are the admin role. These bones are framework-agnostic, so no framework access is required to use this surface.

Annotation · not proposed UISpec ii 4.1 · relationships are organization units, and nothing else. A fact references an organization unit and a coded relationship type. No non-unit "named relationship" identity exists anywhere in I1 to I3, so the picker searches units only and the free-text path an earlier draft of this page drew has been removed: it would have introduced a second identity model the spec forbids. The consequence a reviewer should weigh: a value chain relationship that matters enough to carry a fact has to exist as an organization unit outside the reporting boundary first.

Annotation · not proposed UIBoundary demarcation, drawn in one line above the table. Gate (c) bone 1A separates units inside the reporting organization from relationships outside it, with the inside case carrying the reserved demarcation on the organization model (ORG_BOUNDARY) and everything else recorded here as a value chain relationship. Question for the PM: the spec names the demarcation but not its user-facing treatment, so the reserved code is drawn as an internal value and never offered in the type dropdown. Confirm that reading before build.

Annotation · not proposed UINo partner registry, by design. Facts are entered aggregates with their own scope, method, period, and provenance. They are never derived from a list of named partners, and nothing on this page creates a partner record. A partner model, if it ever arrives, is additive and is not a migration of these facts (gate (c) bone 1A, development plan).

Annotation · not proposed UIOmission exclusivity. The values-or-omission choice in the form is the same closed rule the cycle's own data entry surfaces use (spec ii 3.9 and 3.10): exactly one payload slot is legal, an omission is mutually exclusive with any payload, and each save is a single atomic write that unsets the slots it is not using. I1 validates the omission's shape only; when an omission is permitted is an I3 question. The omission fields drawn on the form are the same three the entry pages draw (reason, explanation, expectedAvailability), because it is the same contract, and the wholesalers row shows what a saved one reads like. Switching a saved fact between the two raises the same confirmation drawn on page 5 of this wireframe set, which is the one switch-away pattern for the whole wireframe set.

Annotation · not proposed UISpec ii 4.1 · a fact carries values or an omission, never neither. The payload rule added at this wireframe round: numerator is REQUIRED, denominator and unit are optional, OR the fact carries an omission. A scope-note-only "fact" is not a legal state, so this page no longer draws one: the waste contractor row that used to read "Scope note only" now carries 1 of 1, and its scope sentence sits where scope sentences belong, beside the number rather than instead of it. The form marks the numerator required for the same reason. The rule exists because a qualitative note recorded as a confirmed fact teaches implementation a third payload shape the matrix does not have.

Annotation · not proposed UIRevision history. A confirmed fact is immutable; an edit writes a new revision row, keeps the prior revision with a supersededByRevision pointer, and clears confirmation on the new revision. The expanded strip on row 1 is that history, drawn inline rather than in a separate dialog so the reviewer sees the chain without leaving the fact list. The mechanics are drawn up close on page 11 of this wireframe set.