Jijibora Tie-In — Real Estate Reuses the Jijibora Smart-City Infrastructure

Audience: Product, platform, and implementation teams
Purpose: Show how the real estate packages reuse the existing Jijibora building/reflex/community infrastructure — Jijibora's native target market
Sources: docs/platform-map/jijibora/, docs/playbooks/, docs/platform-map/system/

1. The Core Idea

Jijibora is the platform's smart-city/community framework: buildings and communities react to their own state through declarative reflex rules, sourcing, governance, and starter packs. Jijibora's stated target market is master-planned developments, retirement estates, golf/lifestyle communities, and bedroom/commuter estates — exactly the large residential complexes this document set targets.

The real estate packages do not build a new vertical. They configure the existing Jijibora primitives (claims, truth graph, reflex rules, scenario packs, starter packs) for real-estate-specific CNS types and lookups: units instead of parcels, owners instead of citizens, service charges instead of community levies, defects instead of potholes, and HOA governance instead of community governance.

2. Direct Mappings — Real Estate Domain → Jijibora Primitive

Real Estate Package	Jijibora Equivalent	Reuse Point
PK-01 Sales & Off-Plan	Building reflex: space ownership; `rent-lease-register.rule.json`	Unit = space entity; sale = title registration analogue
PK-02 Unit & Title	Ontology entity-space spine; `home_ke` building-bound pattern	Unit ownership = parcel/title binding; append-only history
PK-03 HOA & Community Governance	Community governance (`s165-s166`); scope rules; AI personas	HOA rules = community rules; votes = governance votes
PK-04 Maintenance & Facilities	Building safety inspections scenario; public-space rounds rule	Defect = inspection stage; work order = rounds ticket; expert sign-off guard
PK-05 Leasing & Rental	Lease register pattern; tenancy semantics	Lease = tenancy agreement; deposit = escrow analogue
PK-06 Amenities Booking	Mall tenancy booking/deck reservation pattern	Amenity slot = stall/board booking; time-bounded lease
PK-07 Service Charge & Finance	Community sourcing + threshold routing	Service charge = community levy; collection = sourcing fill
PK-08 Construction & Snagging	Building compliance inspection (7-stage chain)	Snag = inspection defect; handover = certificate issuance
PK-09 Resident Services & Access	Access/lease grid; identity plane	Access rights = lease-based access; visitor = temporary access
PK-10 Resale & Secondary Market	Title transfer pattern; ownership edges	Resale = secondary title transfer

3. Reused Jijibora Artifacts

Jijibora Artifact	Real Estate Use
`rent-lease-register.rule.json` (jijibora-property-compliance)	Unit lease/ownership register; append-only ownership history
`building-safety-inspections.scenario.json`	Snagging/defect inspection chain: scheduled → inspect → expert sign-off → certificate → handover
`mall-tenancy.rule.json` (jijibora-facilities)	Amenity booking (time-slot lease); visitor access (temporary booking)
`lookup.claims.sod.v1`	Defect inspector ≠ contractor; service-charge issuer ≠ collector
`lookup.claims.threshold.v1` / `.procurement.v1`	Service-charge rate bands; maintenance procurement approval tiers
Solver Gateway `procurement.basket_split@1`	Vendor selection across multiple developments (bulk landscaping, security)
`s184_record_federation`	Developer → HOA → property manager record boundaries
`s142_scope_governance_authority`	Developer → HOA board → committee delegation chains
`s230_app_permissions` (APF)	Role-based access per entity (developer, HOA, property manager, resident)
`s131-s150` PoCE lifecycle	Sale agreement, lease, service-charge collection, vote, defect closure receipts
Starter pack model (`jijibora-starter-packs/`)	Real estate starter packs: Sales Office, HOA Office, Facilities Desk, Finance Desk

No new tables. No new schema. No bespoke real estate vertical. The real estate packages are declarative configuration (CNS types, lookups, scenario packs, starter packs) on top of the same substrate Jijibora already runs on.

4. Example — Snagging Reuses the Building-Safety Inspection Chain

Jijibora's building safety inspections ("inspect large buildings: fire, accessibility, hygiene → expert sign-off → certificate → packet export") maps directly to real-estate snagging:

Jijibora: building → fire inspection → accessibility → hygiene → expert sign-off → certificate → packet export (7 stages)
Real estate: unit → snag inspection → defect list → contractor fix → inspector sign-off → handover certificate → defects archive

Same seven-stage shape, same expert-sign-off gate, same PoCE receipt — different CNS type and lookup values.

5. Example — HOA Governance Reuses Community Governance (s165)

Jijibora's community governance (scope rules, compliance policies, proposals, elections) maps directly:

Jijibora: community → scope rules → proposals → votes → elections → amendments
Real estate: development → HOA rules → resolution proposals → owner votes → board elections → rule amendments

Same governance engine, same BBS+ voting, same scope-bound delegation — different domain.

6. Implementation Consequence

Because real estate reuses Jijibora infrastructure:

Deployment: same surreal import strata order; no new schema deployments
Seeding: real-estate CNS types + lookups added to datasets/lookups/ and datasets/scenarios/; seeded via scripts/seed-nats-kv-declarative.mjs
Testing: same verify scripts (NATS judge + Surreal cross-checks); no new test surface
Operations: same starter-pack bring-up, Soft-first, live-gate ritual

7. Positioning for Real Estate Buyers

Tell a developer or HOA: "You are not buying a real estate system. You are activating the same community-operations backbone that powers smart cities and master-planned estates — units instead of parcels, owners instead of citizens, service charges instead of community levies, HOA votes instead of community resolutions — with the same audit, federation, and fail-closed guarantees that Jijibora was built on."