Treatment: core interpretive object. Center of the chain. Load-bearing interpretive primitive in v0 planning.

Purpose: capture a claim or premise embedded in a public plan, policy, inventory, program, APR, capital plan, infrastructure plan, or related document. The project tests assumptions for current plausibility under changing conditions.

Candidate fields:

• a unique identifier;
• the verbatim text of the assumption;
• the source document or dataset where the assumption is embedded;
• the location within that source (page, table, section, parcel reference, etc.);
• the original date of the assumption (when it was stated, not when it was inspected);
• the context (Housing Element / APR / Capital Plan / etc.);
• the relevant supporting objects this assumption references (one or more OpportunitySite, HousingProject, PolicyProgram, etc.);
• the attachment scale (see below).

Attachment scale: an Assumption is not necessarily tied to a single site or project. Assumptions may attach to:

• a specific site (e.g., an opportunity-site capacity assumption);
• a specific project (e.g., a project's delivery expectation);
• a typology or corridor (e.g., expected redevelopment across a class of sites);
• a program or policy (e.g., expected outcomes from a rezoning ordinance);
• an aggregate strategy (e.g., total ADU / small-infill production assumed across many parcels at once).

The ontology should not force per-site framing on aggregate strategies. A residential parcel's individual capacity assumption may be effectively zero or fractional while the aggregate strategy that includes it carries meaningful weight. The chain should be able to test assumptions at the scale they were stated.

Source / provenance requirement: every Assumption cites the source document or dataset from which it is drawn, with the location within the source identified.

Relationship notes: referenced by ImplementationSignal (signal-anchored to assumption) and ImplementationFinding (finding tests one or more assumptions). May reference one or more supporting objects via a relevant_objects association; the exact mechanism (polymorphic list, typed relations, etc.) remains operator-pending.

What stays conceptual: field-level schema; the relevant_objects reference mechanism; the controlled vocabulary for context; whether aggregate-attachment cases need their own object class or remain a parameter of Assumption.

Treatment: core interpretive object. The source-anchored interpretive observation.

Purpose: capture a public-data observation that bears on whether one or more assumptions remain supported, weakened, contradicted, or uncertain.

Candidate fields:

• a unique identifier;
• the assumption(s) the signal bears on (one or more Assumption references);
• the signal text (free-form description of what the signal asserts);
• the source document or dataset cited;
• the retrieval / access date;
• the relevant location within the source;
• the signal subtype (one of the candidate subtypes; see §Candidate signal subtypes);
• the direction of the signal relative to the assumption: supports, weakens, contradicted, or uncertain;
• confidence (see §Confidence and provenance);
• known / inferred / missing status of the underlying fields.

Signal aggregation policy: multiple similar raw records may be summarized as one ImplementationSignal where they support the same interpretation about the same assumption — for example, a series of related permit records that collectively bear on a single assumption can be summarized as one signal rather than recorded as many separate signals. The summary signal cites the underlying records. The choice between per-record signals and summary signals is operational and depends on whether the underlying records carry distinct interpretive force.

A row in a database is not a signal. The interpretation that the row's content weakens or supports a specific assumption is the signal. The interpretive step is real and load-bearing.

Bounded absence of a record can also count as signal evidence, when the source searched, the search scope, the time horizon, and the expected downstream record are explicitly defined. For example, a sustained absence of any DBI permit activity on a parcel over a defined horizon — anchored to a Pipeline approval date and to a specific downstream-record expectation such as a building permit application — is an interpretable signal about whether an approved entitlement is advancing. The signal is bounded absence, not absence in the abstract; an unbounded absence is not interpretable. Provenance discipline still applies: the bounding parameters must be cited along with the source.

Source / provenance requirement: every signal cites a retrievable public source with retrieval date. Outputs without provenance are not the same artifact class as outputs with provenance (see methodology.md).

Relationship notes: anchored to one or more Assumption records. Synthesized into ImplementationFinding records. May reference supporting objects via the same relevant_objects mechanism used by Assumption.

What stays conceptual: field-level schema; direction-label final vocabulary; aggregation policy (whether summary signals get their own record class or remain a summary flag on a signal); cross-signal clustering as a higher-level pattern.

Treatment: core interpretive object. The primary interpretive artifact.

Purpose: the interpretive synthesis produced by comparing one or more assumptions against implementation signals. A finding is what the project publishes; everything upstream (assumptions, signals, supporting objects) is the apparatus that produces the finding.

Candidate structure (mirrored from object-model.md):

Assumption being tested:
Relevant object(s):
Observed signals:
Interpretation:
Direction: supports / weakens / contradicted / uncertain
Confidence: low / medium / high (with basis)
Possible intervention candidates:
Sources:

Three-layer assessment treatment: the method operates with three distinct assessment layers; they are deliberately not collapsed:

• Signal-level direction. The direction of an ImplementationSignal relative to the assumption it anchors to (the signal-level field listed in §ImplementationSignal candidate fields above). Working vocabulary: supports / weakens / contradicts / uncertain.
• Matrix row-level assessment. The reading of one document-claim row against its supporting and weakening evidence within the Living Implementation Consistency matrix (see methodology.md). Working vocabulary: confirmed / weakened / contradicted / unresolved / not yet testable.
• Finding-level composite treatment. When the row assessments within a finding diverge, the finding-level reading is composite. The composite is explained in the finding's interpretation prose rather than forced into a single controlled value. No controlled enum is committed for finding-level composite treatment.

Manual chain extraction has surfaced cases where a single direction value does not capture the implementation condition cleanly — for example, an entitled-but-not-advancing case where row assessments diverge across the surface-specific readings of inventory snapshot, entitlement event, rolling advancement, and completion. The row-level vocabulary has held across operator-side scratch extractions but is not yet expert-reviewed. Final controlled vocabularies remain deferred to later prototype work.

Cross-cutting findings: some findings are not about a single assumption but about a pattern across many (e.g., a typology-level drift pattern). These are aggregate findings that reference multiple constituent findings; the mechanism (cross-cutting object class vs attribute on ImplementationFinding vs narrative-only) remains operator-pending.

Source / provenance requirement: a finding cites both the assumption's source and the constituent signals' sources. Public phrasing follows evidence-supported implementation-sensitivity language, not failure language (see methodology.md).

Relationship notes: synthesized from Assumption + ImplementationSignal records. May surface zero or more InterventionCandidate records. Carries an ImplementationRisk classification.

What stays conceptual: final direction vocabulary; cross-cutting / aggregate finding mechanism; whether findings can themselves chain (a finding citing other findings as evidence).

Treatment: core, downstream, non-prescriptive. Attached to findings as an option set.

Purpose: a downstream, non-prescriptive option that could plausibly change the trajectory of a weakened or contradicted assumption. Candidates are surfaced, not endorsed.

Candidate fields:

• a unique identifier;
• the finding(s) the candidate is attached to (one or more);
• the candidate text (free-form description of the option);
• the actor type the candidate is addressed to (one of: city / county / state / regional / private / hybrid; controlled vocabulary candidate, not final);
• the evidence basis (free-form reference to the analogous prior interventions, named policy programs, or conceptual basis for surfacing the option);
• confidence;
• dependencies on other interventions, infrastructure, or policy actions.

Discipline:

• vocabulary: "candidate," not "recommendation";
• plural where possible: surface multiple candidates per finding to signal the project is mapping the action space, not choosing inside it;
• conditional language: "if [actor type] wanted to address [the weakened assumption], possible candidate interventions include…" rather than "[actor] should do X";
• actor-typed: candidates carry an actor-type tag so they read to their potential audience without becoming a directive to that audience;
• basis-cited: candidates do not appear without basis (analogous prior interventions, named policy programs, or conceptual options).

Source / provenance requirement: tied to a finding; cites the same provenance chain as the finding it attaches to.

Relationship notes: attached to one or more ImplementationFinding records. May reference PolicyProgram records (where the candidate cites an analogous program).

What stays conceptual: the cross-finding mechanism (whether a candidate can reference multiple findings as one object or only one finding at a time); the actor-type vocabulary final set.

Treatment: supporting object (first-class).

Purpose: a Housing Element opportunity site. The anchor object for the citywide signal-card pass.

Candidate fields:

• a unique identifier (typically Block / Lot);
• address;
• parcel reference (BLKLOT, mapblklot);
• Housing Element capacity assumption (planned unit count, planning typology);
• current use / existing condition;
• ownership type (where available);
• supervisor district / planning district / neighborhood;
• environmental and infrastructure flags (where available).

Relationship to HousingProject: linkable via relationship statuses (direct_match, nearby_or_related, citywide_context, inventory_only). See §Relationship statuses.

Source / provenance requirement: every populated field cites the source (typically Housing Element site inventory + parcel / assessor GIS overlay).

Relationship notes: anchor for Assumption records about per-site or aggregate capacity. Referenced by ImplementationSignal records (permit, pipeline, market, infrastructure, environmental, current-use, participatory). Carries an ImplementationRisk classification at the signal-card level.

What stays conceptual: field-level schema; the typology list (categories of opportunity sites are not hard-coded before reviewing the actual inventory).

Treatment: supporting object (first-class).

Purpose: a project in the citywide housing pipeline. Separate from OpportunitySite, linkable via relationship statuses.

Candidate fields:

• a unique identifier (e.g., planning case number);
• address;
• parcel reference (BLKLOT);
• project name;
• current status;
• proposed unit count;
• affordable unit breakdown;
• entitlement and permit dates;
• planning district / supervisorial district.

Relationship to OpportunitySite: linkable via relationship statuses. A HousingProject not on an HE inventory site can still be a citywide_context signal source.

Source / provenance requirement: every populated field cites the source (typically SF Development Pipeline, Planning applications, DBI permits, Housing Production datasets per source-strategy.md).

Relationship notes: referenced by ImplementationSignal records about project-level activity. Pipeline status is itself a signal class.

What stays conceptual: field-level schema; the controlled vocabulary for status values.

Treatment: supporting object (first-class). Provenance anchor.

Purpose: a public document or dataset cited as provenance. First-class so that every signal, finding, and signal-card claim can be inspected to its source.

Candidate fields:

• a unique identifier;
• name (human-readable);
• owner (agency or publisher);
• URL or path;
• retrieval / access date;
• tier (A / B / C per source-strategy.md);
• notes (caveats, data-quality notes).

Source / provenance requirement: the Source object is the provenance discipline. Every other object that makes a claim cites one or more Source records.

Relationship notes: referenced by Assumption (the source of the assumption), ImplementationSignal (the source of the signal), ImplementationFinding (cumulative source citations), InterventionCandidate (where the candidate cites analogous programs or prior interventions).

What stays conceptual: controlled vocabulary for tier (A / B / C is the working set per source-strategy.md); the cataloging mechanism (whether Source records live in their own file or are referenced inline).

Treatment: supporting object (light). Minimal v0 detail.

Purpose: a city or state policy or program relevant to Housing Element implementation (rezoning, adaptive-reuse ordinance, financing program, affordability incentive, etc.).

Candidate fields:

• a unique identifier;
• program name;
• jurisdiction;
• brief description;
• relevance flag or tag.

Source / provenance requirement: cites the ordinance, program documentation, or policy decision record.

What stays conceptual: deeper modeling of program structure, eligibility rules, funding mechanism, etc. — these are deferred. v0 carries program references as anchors, not as full program models.

Treatment: supporting object (light). Minimal v0 detail.

Purpose: an upstream constraint (utility, transit, sewer, capital sequencing) that affects what an OpportunitySite or HousingProject can deliver.

Candidate fields:

• a unique identifier;
• type (utility / transit / sewer / etc.);
• brief description;
• reference (capital plan, transportation plan, infrastructure-capacity document).

What stays conceptual: deeper modeling of capacity, sequencing, and timing — these are second-pilot-phase work. v0 carries dependency references as anchors.

Treatment: supporting object (light). Not the core primitive (per object-model.md cautions).

Purpose: a regulatory, environmental, or policy constraint on a site or project.

Candidate fields:

• a unique identifier;
• type (regulatory / environmental / policy);
• brief description;
• reference.

What stays conceptual: deeper modeling. Per the cautions in object-model.md: do not make Constraint the core primitive — the project risks becoming a static constraint inventory rather than a continuously-interpretive system.

Treatment: supporting object.

Purpose: observed outcomes (delivered units, withdrawn projects, abandoned entitlements). Counted at the completion milestone.

Candidate fields:

• a unique identifier;
• type (units delivered / project withdrawn / entitlement abandoned / etc.);
• count or extent;
• date observed;
• related OpportunitySite or HousingProject;
• source.

Source / provenance requirement: cites the production dataset, status change record, or other observation source.

Treatment: output classification / classification field. Attached to an ImplementationFinding or to a signal card; combines direction, confidence, and structural conditions into a quick-scan tier.

Candidate vocabulary: working tier values exist in repo-level prose (e.g., low / elevated / high / uncertain). The final controlled vocabulary remains deferred.

Why not its own object: would duplicate ImplementationFinding's direction and confidence fields.

Treatment: direction label. Describes change over time in feasibility at the aggregate, typology, or corridor level.

Why not its own object: longitudinal change over time is captured as a finding-direction descriptor in v0's snapshot framing. A future longitudinal phase may justify graduating it to an object class.

Treatment: direction label. Describes per-site, per-assumption drift over time.

Why not its own object: same as FeasibilityShift.

Promoting any of these three to objects would duplicate the chain's direction and confidence fields and would prematurely add overlapping "direction-of-change" classes. They are useful project vocabulary, not separate schema entities in v0.

Treatment: reporting surface / attribute on Assumption. Not a top-level object in v0.

Purpose: a reporting-side concept (e.g., "Authorized Units," "Pipeline Units," "HE opportunity-site capacity," "Major Multiphase Projects"). A reported category is a surface from which assumptions can be extracted or inferred. Treating it as an attribute on Assumption (i.e., "this assumption is associated with reported category X") is the lightweight pattern.

Why not its own object in v0: the lightweight attribute pattern has been pressure-tested in operator-side scratch examples and is held as the v0 working pattern. Promoting ReportedCategory to a top-level object would require schema commitments about its fields, vocabulary, and relationships that the lightweight pattern does not yet need. The placement decision can be revisited if future cases break the lightweight pattern; v0 retains it as the working approach.

What stays conceptual: the final placement (object class / attribute / surface concept), the controlled vocabulary for category names, and the mechanism by which Assumption references ReportedCategory.

For documenting a reported category and the assumptions behind it, the following candidate planning pattern can be used:

Reported category:
Counting rule:
Source:
Explicit assumption:
Implied implementation assumption (analyst-defined):
Signals needed to test it:
Possible interpretation:
Confidence:

This is a candidate planning pattern, not a final schema. The first six rows map cleanly to fields and definitions present in source datasets and HCD forms. The "Implied implementation assumption" row is analyst-defined and is not attributed to the city or to HCD — Urban Observatory's role is to articulate what an implementation reading of the reported category would test, then to look for the signals.

Treatment: reusable attribute. Not an object.

Candidate vocabulary: low / medium / high. Final vocabulary remains deferred.

Every confidence value carries a basis-of-confidence prose field explaining what the level is grounded in (signal redundancy, source authority, freshness, internal consistency, etc.). The basis-of-confidence taxonomy itself is conceptual; v0 documents it as free-form prose rather than enumerating final basis values.

Treatment: reusable attribute. Per-field status.

Candidate vocabulary: known / inferred / missing / uncertain.

Applied to populated fields where the source confidence is variable (e.g., a signal card field that is directly sourced is known; a field reconstructed from related signals is inferred; a field with no usable source is missing).

Per methodology.md and source-strategy.md, every claim the method produces should be inspectable to its source. Each source contributing to a signal, finding, or signal-card field is recorded with:

• the source document or dataset;
• the retrieval date;
• the relevant location within the source;
• the confidence in the interpretation derived from it;
• any limits or caveats the source carries.

Outputs without provenance are not the same artifact class as outputs with provenance.