Organization Core — contract inventory (ST-931)

Where identity, authorized scope, selected scope, target, freshness, enforcement and outcome actually live in propflowai today — per entry-point family, with the existing test that exercises each and the board row that owns each gap.

Inspected commit 94172a0fad7ba2170f60345521455d98ffcd2d4c (propflowai origin/main, 2026-09-16 16:37:56 −0500) · board read at propflow-docs f4e676628c9489f750f631de51f886275d9c73c9 · deliverable of board row p10-core-contract · this is an inventory, not a completion receipt

How to read this page

Every implementation claim below names a file and a line at the inspected sha. Claims are labelled by how they were established:

• executed — a command was run in a worktree pinned at that sha and its output is quoted. There are exactly three.
• UNVERIFIED — a concrete concern that a forbidden-read or forbidden-effect control has NOT yet proved. It is a hypothesis, and this page never upgrades one to a finding.
• inspected — the file was read, or a git grep was run and its count recorded. Everything else.

Counts from git grep are ceilings, not measurements of behaviour: a grep proves absence only of the spelling searched, and presence only of a string. Every zero reported on this page was run in the same command as a spelling known to be present, so that a zero caused by a bad path or a shell-glob failure would have shown up as a zero on the control too. Where that control is not stated, treat the zero as unverified.

1 · The PC1 envelope already exists as a type

PC1 asks for a logical envelope carrying verified actor or workflow identity, authorized scope, this request's selected scope, canonical target ids, coverage, the relevant revision basis, and for writes an operation identity and explicit outcome. No new universal context type is needed. TenantContext already carries all but two of those, and four sibling context types exist beside it.

The five minted context kinds are TenantContext :200, AdminContext :232, ComplianceContext :241, LifeSafetyContext :251, and the reports context. Their non-test caller census at this sha:

Controls for those zeros, run in the same commands: mintFooBar → 0 while the six rows above returned non-empty; mintAdmin → 5 files under the identical exclusion filter that gave mintLifeSafety/mintReports zero. The minters are exactly eight — mintFromAddress :528, mintFromSession :592, mintFromSnapshot :663, mintFromConversation :731, mintForJob :790, mintAdmin :833, mintLifeSafety :861, mintReports :874. Files importing portfolio/context/mint at all (non-test): 6. Exactly one route handler touches the context machinery, and through mintAdmin.

2 · One authoritative source per responsibility — and the three that have two

3 · The grid — entry-point family × chain stage

Each cell names where the stage is decided, or says it is not decided. +/− means a positive and a negative control exist for that stage in that family; + only means no negative control was found; none means neither.

4 · Per family — entry points, harness, controls, owning row

A · User APIs — 462 route handlers

• Count: git ls-files 'src/app/**/route.ts' → 462 (459 under src/app/api, plus logout, native-auth, robots.txt).
• Boundary is a trio, not a facade: platform/auth/helpers.ts (identity + refusal), auth/scope.ts (property leg), auth/org-scope.ts (org leg), plus require-in-roster.ts (roster leg). There is no module named fence — 736 files match the word and every one is ordinary English or an unrelated fence (markdown, idempotency, import-closure).
• Coverage: 281/462 import the trio. 181 do not; ~118 of those have a different, appropriate door (webhook signature, Stripe signature, bearer, invite token) and 63 have no recognized door in the route file itself — several of which are fenced transitively in a shared loader, verified for api/tenants (load-tenants-list.ts), api/properties/[id]/units/[unitId] (load-unit-detail.ts) and api/collections/[tenantOccupancyId]/case-ref (resolve-account.ts:63, which calls requireUser :67, getUserOrgScopeForPropertyScopedRoute :76 and isPropertyScopeDenied :80).
• Harness entry point: src/__tests__/require-in-roster-armed.test.ts, require-in-roster.test.ts, require-in-roster-membership.test.ts, scope.test.ts, rbac-security.test.ts; route level src/app/api/conversations/__tests__/route.org-isolation.test.ts and src/app/api/properties/[id]/__tests__/cross-org-property-id.test.ts.
• Positive and negative controls: both present. require-in-roster-armed.test.ts:101 is labelled by its author "⚠️ THIS IS THE FAIL-BEFORE" and asserts denied === true; :117 is the dark-default control — the identical request with the gate off is allowed and expect(fetchProperty).not.toHaveBeenCalled(). scope.test.ts:187/214/239 assert an empty scope yields zero rows; :262 asserts an out-of-scope id is refused. Route level: route.org-isolation.test.ts:168 expect(body.items).toEqual([]); cross-org-property-id.test.ts:326/340/356/375 assert 404.
• Mock-vs-real, measured over 364 test files that touch the auth modules: 81 vi.mock the scope math itself; 246 mock only auth/helpers, so identity is stubbed and the scope math runs real (101 of those use importOriginal); 36 mock none. The fence's own unit tests (scope.test.ts, rbac-security.test.ts) mock nothing at all.
• Owning rows: p1-roster-refuse (the gate flip), p7-actor-view (the stored list), ui-s-a / ui-s-d (the consumer sweep).

B · List/detail reads — 155 page.tsx, 114 server-rendered

• Two mechanisms coexist. New: mintSelection() (get-selection.ts:85), used by roughly 2 of ~15 list pages (vendors, leasing/prospects). Old: loadPropertiesList(await headers()) → getUserPropertyScope/getUserOrgScope → in-memory filtering at load-properties-list.ts:55-64.
• Not a fourth duplicate. mintSelection is a sibling entry point, not a second derivation: it calls the same resolveGrantsFor, chooseProposal, deriveSelection and scopeKey as readScope, and its own comment records why ("This module and read-scope.ts used to hold two separately-written copies of that decision… One function cannot drift from itself"). Its fail-closed claim is real: refusal() at :48 builds {orgs: []} and derives from it, and nothing is caught, deliberately, so a failed read surfaces as an error rather than as "you have no organizations".
• Freshness. ConsistentRead: true appears 38 times in 26 files — it is not unused. But the two authorization legs are both eventually consistent: the grant read getPersonRolesAcrossOrgs is a base-table query (person-roles.ts:134-140) that omits the consistentRead argument, and the roster read that defines the effective property set is a GSI query (dynamo/property.ts:168, :213, called from grants.ts:238) which DynamoDB cannot serve consistently at all. One is fixable, one is not.
• Revocation is a soft archive — person-roles.ts:211-251 endPersonRole sets active=false, endedAt under attribute_exists(PK) — and is honoured by predicate, not by version: every grant read filters r.active (person-roles.ts:139, :119, grants.ts:216). revokedAt exists (203 hits) but belongs to SMS consent and invites; there are zero occurrences in domain/scope or platform/auth.
• Harness entry point: scope/__tests__/read-over-scope.test.ts — the strongest control in the repo for this stage. Nothing is mocked; the subject is the real function and only the injected reader is a spy. Its negative control asserts both halves: expect(await readOverScope('outside', new Set(['inside']), read, 4)).toEqual([]) and expect(read).not.toHaveBeenCalled(). Positive control at :19. Also domain/vendors/__tests__/vendors-read-the-set.test.ts:240 — expect(orgsRead()).toEqual([]) plus expect(rows).toEqual([]).
• gap No negative control for loadPropertiesList or loadTenantsList — which is precisely the older read-then-filter path.
• Owning rows: ui-s-a, ui-s-a-r2-tab-local-selection, ui-s-d, p10-core-freshness.

C · Internal tools / AI — three registries, not one

One cross-cutting fact behind all four: isInScope returns true unconditionally when scope === null (auth/scope.ts:148-152), and getUserPropertyScope returns null only for platform_admin (:96-101). That is the documented Admin exception, not a leak — and it is exactly why ToolContext's own docblock insists the user field is required: "scope alone is the PROPERTY axis and cannot answer the org question".

• Where it is done right, and these are the patterns to copy: get_work_order (tools.ts:1048 + :1078 isPropertyInOrgScope), get_conversation (:1127 + :1144), get_prospect (:1208, an org-partitioned fetch), leasing (tools-leasing.ts:1087-1090, anchor derived at :1047 from getProperty(...).organizationId and deliberately not from Conversation.organizationId, :1030), turnover (_turnover-shared.ts:254-257), work-order mutators (assert-work-order-actor.ts:54).
• Harness entry point: src/app/api/work-orders/__tests__/cross-org-derived-work-order-and-chat-ids.test.ts, which drives the real handleDashboardChatTool and the real isPropertyInOrgScope. Negative control at :392 — a row whose stored property belongs to another org is refused, with four writer spies asserted not.toHaveBeenCalled(); no-existence-oracle companion at :406; positive control at :414. Also turnover-tool-dispatcher.test.ts:217/228 and leasing-tools.test.ts:8832 (which adds a no-leak assertion on the other org's name).
• blind spot, not a defect on its own That suite's census guard at :581 cannot see the four proposed-id readers. It selects call sites with the regex isInScope\(\s*(wo|conv|prospect)\.propertyId\s*,\s*ctx\.scope\) — a guard handed its own scope, which structurally cannot find a reader that gates on an input id rather than a row-derived one. executed npx vitest run src/app/api/work-orders/__tests__/cross-org-derived-work-order-and-chat-ids.test.ts → 28 passed / 28, rc 0. It is green while those four are outside its census. Note what that does and does not show: the guard's coverage is narrower than its subject. It is not evidence that the four are unsafe — §4C's table is the evidence on that, and it says three of them are bounded by the checked id.
• gap No negative control for: the Clara conversational dispatcher against an out-of-scope id (its three tests vi.mock('@/lib/tools/handlers'), so no handler-side scope ever runs); the org axis on the four proposed-id readers; the appfolio_report passthrough; /api/admin/dev/tools/run refusing a cross-org accountId (route.ts:584-585). Each of those is a UNVERIFIED hypothesis until a forbidden-read control exists — this page does not upgrade any of them to a finding.
• Owning rows: p5-texting / p8-pickvendor-* for tool fences, p10-core-scope for the proof, p7-domain-override for the operator route.

D · Background sync — 94 entry points

• 15 Lambda handlers · 1 Fargate service (services/renewal-worker/index.ts:239, 18 queue registrations at :193) · 40 Vercel crons (38 /api/cron/* + 2 /api/admin/*) · 28 scheduled CI workflows · the AppFolio sync lambda with 10 EventBridge rules whose payload is {"jobs": [...]} and carries no organizationId (ensure-schedules.sh:201, :405).
• All 38 cron routes carry no scope. inspected, with control git grep -l "domain/scope" -- 'src/app/api/cron/**' → 0, and in the same call requireCronOrAdminAuth → 38. Their only gate is a bearer-secret comparison (platform/security/admin-auth.ts:64-67) that carries no scope payload at all.
• Six no-argument Lambdas necessarily sweep every org: concession-watcher/handler.ts:95, metric-snapshot/handler.ts:502, metrics-alerts-checker/handler.ts:122, outlook-subscription-renewer/handler.ts:99, company-mailbox-poller/handler.ts:83, and appfolio-sync on its scheduled path (candidate set handler.ts:2034, fan-out :2045). One job enumerates orgs explicitly and unconditionally: domain/leasing/org-listings-sync.ts:678 getOrganizations(). Four scheduled CI workflows write production with --apply.
• a zero on a coined name proves only that the name is unused operationScope, authorizedOperationScope, pinnedContext, systemActor, serviceAccount and backgroundContext all return 0 repo-wide. Those are names this page proposed, not names the codebase chose, and their absence is not evidence that no mechanism exists — the durable lane proves it, where the same responsibility is spelled SnapshotView and mintFromSnapshot. What the cron measurement does establish is narrower and is the claim that stands: no route-layer scope argument. Controls in the same table: orgId 2,637 and tenantId 3,707 — noting that in this codebase tenantId means the renter, not the tenancy key; TenantOccupancy (data/types.ts:17215) carries personId and organizationId as separate fields, and the multi-tenancy root is organizationId (data/interfaces/organization.ts:5-10).
• Harness entry points: 10 of 38 cron routes have a test that drives the real handler (e.g. src/app/api/cron/conversation-capture-drift/__tests__/route.test.ts:33); 17 lambda test files import the real handler; agent-runtime has none.
• gap No isolation control was found for the cron, lambda, Fargate or scheduled-CI families. 274 test files carry cross-org vocabulary; exactly one sits under lambda/ and it is a count-reporting regression (onboarding-import-runner.test.ts:1615 asserting vendorEngagement === 3), not an isolation assertion. This is a statement about these four families: the durable-workflow family does have one (see E), and an earlier head of this page wrongly folded all five together.
• Caveat on the method: the classification greps route.ts for org references. That establishes there is no route-layer scope argument — the contract-level question this row asks — and does not trace whether an individual downstream sweep re-derives a narrower set internally.
• Owning rows: ambiguous — see the routing question in §7.

E · Durable workflows — 36 production workflows

• Registry src/lib/temporal/workflows/index.ts:18-53, one export per line, matching 36 definitions one-to-one. 42 activity modules on disk, 39 registered, across three registration sites (src/lib/temporal/workers/*, services/renewal-worker/index.ts:197,322, and an in-app eval worker at domain/evals/executor/run-session.ts:609,619). startChild and executeChild → 0 repo-wide: there are no child workflows.
• One workflow of 36 pins and re-checks its scope; the machinery is real and mostly dark. collections-chase-workflow.ts:262 calls pinCollectionsScopeActivity behind patched('collections_scope_pin_v1'), storing SnapshotView {organizationId, propertyId, mapVersion}; :320 calls checkpointCollectionsScopeActivity before each notice, which re-mints through the live mintFromSnapshot (collections-scope.ts:136) and returns ok, refused{reason, enforce} or unavailable. The design is documented at length in the activity's own header: a run that sees a map rebind finishes at the new version rather than crashing; a building that changed company yields the named scope_moved, never a 404. The gate state is the finding, not the absence: enforce is true only for scope_moved and only when rosterGateModeFor(propertyId) === 'refuse' (:174-175) — the same switch as requireInRoster, armed today on two bench buildings. Every other refusal, including property_unknown, is recorded and never enforced, deliberately, because the roster GSI it derives from "landed dark and has no recorded prod parity yet". Owning row: p9-workflow-pins.
• The other 35 workflows carry entity ids only; their activities re-derive org from the row they load (243 organizationId references across activity modules). That is a real mechanism, not an absence — what is unproven is whether every one of those re-derivations is correct and whether any of them would refuse a revoked grant. orgScope (268 hits) is HTTP request-time only and does not enter a workflow input; an absent organizationId in an initial input proves nothing about the run's scope.
• Operation identity exists — outside Temporal. domain/voice/provider/contract.ts:246-249 AdapterMutationOptions.operationId, whose docblock states the intent exactly: "the SAME operation key the surrounding write already uses — not a second, adapter-private one." a zero on a coined name proves only that the name is unused effectId, durableEffect, externalEffect, OperationContext, pinnedOrgId and workflowScope all return 0 — but those are spellings this page proposed, not spellings the codebase chose, and the repo's actual vocabulary for the same responsibilities is SnapshotView, mintFromSnapshot, idempotencyKey (1,460), reservation (343) and outbox (275). Read those zeros as "no such identifier", never as "no such mechanism".
• Idempotency is a DynamoDB conditional put taken before the send, not a Temporal feature: temporal/renewal-receipts.ts:279 (attribute_not_exists(PK), keyed on (renewalId, activityName) — deliberately not run-scoped, after the 2026-06 incident where separate runs each minted a fresh key), leasing/outreach-send-claim.ts:111, dynamo/pending-notices.ts:305 and :372. The attempt-stable stamp is temporal/activity-stamp.ts:95, reading scheduledTimestampMs and explicitly not currentAttemptScheduledTimestampMs, which "would look correct, compile, and silently defeat the dedup on every retry".
• Two different pendings. (a) An activity submitted then timed out has no reconciler, by design — the claim paths fail closed and renewal-receipts.ts:246 states "AT-MOST-ONCE, not exactly-once… the claim is stranded and that stage's send is permanently suppressed for the cycle." (b) An effect placed whose provider webhook never fires is reconciled by readback: src/app/api/cron/voice-call-reconciler/route.ts, a one-minute cron, terminal write at :346-366.
• Known idempotency gaps already declared in code: temporal/activities/promise.ts:615-624 ("the REAL fix is an at-most-once claim taken BEFORE the send… not done here… would re-enter the send branch and double-send"); turnover has workflow-level patched() + condition() only, no DB claim (turnover-workflow.ts:403); collections-chase.ts:1224 dispatches without at-most-once protection by design.
• Harness entry points: src/__tests__/workflow-permutations drives the real workflow body but mocks the @temporalio/workflow sandbox wholesale (harness/workflow-mock.ts:29; the README states TestWorkflowEnvironment is deliberately not installed). Seven replay-corpus suites run the real SDK replayer against scrubbed production histories — the strongest real-code harness here. testing-harness/scenarios/run-all.ts drives a live Temporal server but has no npm script and pins @temporalio/*@^1.13.0 against the root's ^1.19.0: treat it as unexercised.
• vacuous control, caught workflow-permutations/tour/tour-scenarios.ts:110 reads like a negative control and is in fact a recorded known-bad baseline — harness/types.ts:101 confirms the guard test does not fail on it. The same shape appears in renewal/renewal-adapter.ts:8-16's arm gate.
• Real negative controls that do exist: renewal-workflow-retry-letter-guard.test.ts:297-308 (a retry does not duplicate; release control at :364; cold-flag control at :408), renewal-send-guard.test.ts:63-75, renewal-receipts.test.ts:124-130 with an anti-lockout control at :153, renewal-sms-real-dispatch-suppression.test.ts:332-348 with a positive control at :351.
• A scope control DOES exist for this family, and it is a real one. src/__tests__/collections-scope-activity.test.ts drives the real pinCollectionsScopeActivity and checkpointCollectionsScopeActivity and the real mintFromSnapshot; only @/lib/data, the snapshot source, the roster-gate module and logging are stubbed. executed npx vitest run src/__tests__/collections-scope-activity.test.ts → rc 0, 10 passed (10). Its negative/positive pair is exactly the gate state: :81 "the building left the company → scope_moved, RECORDED (enforce: false) while the roster gate is off" and :89 "the same verdict is ENFORCED under the roster gate's refuse mode" (enforce: true), with :99 pinning that observe mode records and never enforces.
• gap What is still missing is narrower than "no control": no test revokes a grant and then asserts that a workflow's next effect is refused, and for the 35 workflows without a pin there is no scope control at all. The collections control proves the checkpoint answers correctly; it does not prove a notice was not sent, because the assertion is on the activity's return value rather than on a send spy.
• Owning rows: p10-core-outcomes (ST-935) for the effect proof; the authorization absence is a routing question (§7).

5 · Business records vs minimal authorization metadata

The row asks for this distinction explicitly, because ALIGN2 turns on it: reading the metadata is not permission to read the rows.

Everything else — work orders, conversations, tenants, leases, prospects, tours, renewals, turnovers, vendors, appliances, financial periods, balance history — is a business record, and ALIGN2's intersection must be computed before the query that returns it, not applied to its result.

6 · ST-931 – ST-939 mapped to existing tests

Where ST-931 should be registered — and the problem with that instruction

The row says to record the inventory "in this row's dropdown and existing harness registry". Two candidates exist and neither fits cleanly:

• The registry the Operating Constitution names is not in the repo. docs/OPERATING-CONSTITUTION.md:86 says "The Harness Atlas, the lane page, and this file are the registries." There are 28 references to the Harness Atlas and zero files; nine harness suites cite "Harness Atlas §3.1" for their fixture envelope, citing a document that is not in the tree. This is already recorded twice as unlocated in docs/planning/portfolio-architecture/points-B6.md:53 and :552.
• The registry that actually runs keys on slugs, not ST ids. scripts/portfolio-harness/cases/index.ts:7 ALL_CASES, generated into fixtures/manifest.json (28 entries, derived by fixtures/manifest.ts:52 buildManifest() "so the manifest can never drift from what actually runs", content-locked by fixtures.lock.json, count-pinned by __tests__/manifest-count.drift.test.ts, CI lane .github/workflows/portfolio-harness.yml). Its ids are slugs such as isolation-fail-open-adopts-callers-company; grep -c "ST-" manifest.json → 1. Provenance is carried as provenance.classRef audit-row strings. If "register by ST id" is meant literally, this registry cannot hold it as-is.
• The ST id catalogue itself — docs/planning/portfolio-architecture/how/notes/stress-catalog.md, 1,457 lines, 213 ids — is prose tables, self-described as proposed, and not machine-readable.

7 · Gaps, each routed to an owning row

None of these is a claim that something is broken in production. Each is a path that is unimplemented or unproven, stated as a gap rather than glossed.

8 · Controls discipline — what this page could and could not see

Executed, not inspected — both commands, in a worktree pinned at the sha

Two categorical overreaches, found by a monitor review and corrected on this head

These deserve more space than the searches, because in both cases the individual measurements were right and the sentence built on them was not.

Vacuous controls found — three in the instruments, three in the tests

• Two search passes during this inventory returned all-zeros from a zsh glob failure on an unquoted --include=*.ts — a failed command, not a zero result. Both were caught and re-run quoted. This is why every zero on this page is paired with a present control.
• The count "230 of 462 routes name an enforcing require*" is a ceiling: the grep matches prose comments as well as imports. A stricter import-only pass gives 210. Where the two disagree, the smaller number is the safer one.
• The premise "ConsistentRead is never used", seeded into one of this inventory's own searches, was wrong, and the search refuted it: 38 occurrences in 26 files. A search that had only looked for the expected answer would have published the opposite.
• workflow-permutations/tour/tour-scenarios.ts:110 reads as a negative control and pins a known-bad baseline (harness/types.ts:101). renewal/renewal-adapter.ts:8-16 is the same shape.
• cross-org-derived-work-order-and-chat-ids.test.ts:581 is a census guard handed its own scope by regex, so its coverage is narrower than its subject and it cannot see the four proposed-id readers. That is a gap in the guard; it is not, on its own, evidence about those readers.
• A draft of this page said "mintCompliance has zero production callers". There is no mintCompliance. The caller census excluded the defining file from its own file list, so a symbol that does not exist printed the same "none" as a symbol nobody calls — and "unused" and "not defined" are different findings. Caught by grepping the definitions directly; the eight real minters are now enumerated in §1.

9 · What this page does not claim

• It does not claim any entry-point family is correct. It claims where each family's decision is made and whether a control exists.
• It does not certify any read. Knowing a route calls a guard is not knowing what it passed. That trace is ST-932's.
• It does not close p10-core-contract. The row's own text says so: "Do not claim the docs PR completes this task."
• It assigns no ST id that the board has not assigned, and invents no decision.
• It does not conclude that a mechanism is absent from a search that found nothing. A zero on an identifier this page coined says only that the identifier is unused. A zero on an import says only that that module is not imported. Neither is a statement about behaviour, and both produced a false claim on an earlier head (§8).
• It prescribes no fence, no new universal scope layer and no gate arming. Phase 10 is verification; where a path looks wrong it is routed to the row that owns the behaviour.
• Every count here is a git grep or a file read at one sha. Three commands were executed. Everything else is inspection, and is labelled as such.