JJijibora Docs
docs.jijibora.online
On this page (7 sections)

S-08 — Governance Rules for Your Building and Community (Stakeholder Guide)

Scope: How your community's rules become enforceable, where they apply, and what proof you receive when a rule is exercised inside a building, estate, or district. Status: as of 2026-11-09 Blueprint sources: Playbook Registry — What You Can Run, Who Runs It, What You Get Back; S-04 — Week in Review (plain-language summary); docs/jijibora-gtm/01_MARKET_AND_CUSTOMER.md; docs/jijibora-gtm/08_SECURITY_AND_COMPLIANCE_POSTURE.md; docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md

What this means for you

Your building or estate already has a way to define who lives where, who fixes what, and who may approve a payment. What changes with this governance set is that those expectations stop being memos and start behaving as active rules: they watch real events, refuse unsafe shortcuts, and produce a verifiable record you can hand to an auditor or a donor (source: docs/jijibora-gtm/01_MARKET_AND_CUSTOMER.md; source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).

In plain terms, there are four kinds of rules at work in your property. Each kind does one job, and together they answer the question every resident and board member asks: "Who decided this, under which rule, inside which boundary, and where is the proof?" (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).

Details

The four kinds of governance rules, and what each does for a property

1. Scope rules — who may decide inside this community or building. A scope rule says which group of people is entitled to make a decision for a given place: the whole estate, one block, the gate team, the owners' assembly, or a parent district. It is the boundary of legitimate authority. A decision made outside that boundary does not count, even if someone with good intentions made it. The community ticket playbook, for example, is run by the estate manager desk under its own assembly rules, and a resolver cannot approve their own close-out (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).

2. Compliance policies — what must be true before anything advances. A compliance policy says what evidence, thresholds, and separation of duties must be satisfied before a request can move forward. Examples:

If any of these conditions is missing, the step is refused. The system never fills the gap with a plausible substitute (source: docs/jijibora-gtm/08_SECURITY_AND_COMPLIANCE_POSTURE.md).

3. Spatial rules — where a rule applies. A spatial rule ties a requirement to a physical area: this estate, that block, the school wall, the pump house, the parking deck, the market boundary. The same building stock may carry different rules in different places, and a rule for one ward does not leak into the next. In the connected municipal workflow, the senior level can set a non-negotiable service standard such as a maximum repair time for a public water point, and each ward inherits it but may only tighten it, never loosen it behind closed doors (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).

4. AI advisory rules — what the assistant may suggest but never decide. The assistant can summarise, draft, or suggest, but it cannot approve, release funds, or close a ticket on its own. Advisory hooks are present but off by default in the existing packs, and turning them on is a product choice by the community, not a technical missing piece (source: S-04 — Week in Review (plain-language summary); source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs). The governing principle is "artificial intelligence proposes, people decide" (source: docs/jijibora-gtm/08_SECURITY_AND_COMPLIANCE_POSTURE.md).

Everyday cases: what happens in order, who gets to act, what proof you receive

Case 1 — Night-time misbehaviour by guard staff near the automated emergency device. Night reports arrive through the same ticket flow as any repair. The resident opens a community ticket; the resolver assigned to that building is the only role entitled to triage it; triage evidence (a short note of time, place, and what was seen) is mandatory before the ticket can advance. Because night-time incidents are high severity, the assembly quorum rule can be selected, meaning a single person cannot close the matter alone. You receive: the ticket journey receipt showing who reported, who triaged, who resolved, and whether the time limit was met. What the system refuses: a close-out without triage evidence, and a close-out by the person who created the ticket where separation of duties applies (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back; source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs).

Case 2 — Parking, elevator, or gate dispute that needs escalation. Routine estate tickets follow the resolver path. When severity rises, the playbook escalates: the parent ticket stays open while a child vendor or facilities subtask is opened inside the parent's limits, and the child cannot widen those limits. The board or assembly becomes the approver for high-risk matters, not the individual guard or caretaker. You receive: a parent-child receipt tree, so you can see the original complaint, every subtask, and exactly who closed each step. What the system refuses: a child subtask that tries to exceed the authority its parent was given (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).

Case 3 — Library, pole, or shared-plant compliance audit. When an auditor asks "prove the library lighting, the pole signage, and the pump service were inspected on schedule," the estate does not reconstruct answers from chats. Each inspection is a controlled claim with required evidence: an assessment note plus a photo reference, and for property lines under litigation, the inspection reference itself. Threshold rules decide how many approvers are needed based on amount and risk. You receive: the evidence checklist, the approval chain, and an exportable audit pack showing the sequence is intact and unedited. What the system refuses: any step where required evidence references are absent (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back; source: Claims Plane — Processing Claims, Guarded Transitions, and Declarative Packs).

Case 4 — Leasing, licence, or boundary crossing. When a tenant, vendor, or asset moves across a governed boundary — for example a leased unit inside the estate, a vendor crew entering the pump house, or an asset crossing into the neighbouring block — the spatial rule names which group's authority governs the destination. Entry without that standing is refused, and the crossing itself is recorded. You receive: the boundary event record showing what crossed, from where to where, and under which lease or permission. What the system refuses: access that falls outside the destination authority, and any claim that a record was shared with a peer where the sharing was not authorised (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; source: docs/jijibora-gtm/08_SECURITY_AND_COMPLIANCE_POSTURE.md).

What to ask before signing

  1. Which four rule kinds are in scope for our estate, and who is the named owner of each rule? UNKNOWN — confirm with the vendor for your deployment.
  2. May we see one live, guarded ticket run end to end, including a refusal case where evidence is missing? (source: S-04 — Week in Review (plain-language summary))
  3. What proof do we receive per decision — the step-by-step chain, the approver identities, and an export the auditor can recompute without trusting the vendor? (source: docs/jijibora-gtm/08_SECURITY_AND_COMPLIANCE_POSTURE.md)
  4. Who may change a rule after go-live, and does the change preserve a visible history rather than overwriting it? UNKNOWN — confirm the amendment and voting procedure for your community.
  5. Are the assistant's suggestions advisory-only in our pack, and can we keep them off? (source: S-04 — Week in Review (plain-language summary))
  6. Which decisions require an assembly or cross-group quorum in our estate, and who calls that assembly? UNKNOWN — confirm for your legal entity and bylaws (source: docs/jijibora-gtm/01_MARKET_AND_CUSTOMER.md).
  7. What happens to resident and tenant data when a person leaves, and is erasure available in our deployment? The design calls for a key-destruction approach to erasure, but its availability in a given release remains an open item (source: docs/jijibora-gtm/08_SECURITY_AND_COMPLIANCE_POSTURE.md).

Open items / gaps

  • Customer-held signing roots, receipt records of which ceiling was in force, and field-level redaction on federated sharing are all recorded as in-flight or not shipped in the security posture; do not accept the contrary as a present fact (source: docs/jijibora-gtm/08_SECURITY_AND_COMPLIANCE_POSTURE.md).
  • Advisory behaviour, trusted timestamping, and public-safety location formatting appear only when the corresponding customer or product choice is present; packs cannot declare themselves live (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).
  • Pricing, savings amounts, and percentage cost claims are intentionally omitted from this guide; no vendor price or savings metric is asserted here. UNKNOWN — request the commercial schedule separately if needed.
← BackHome — all documentationNext →Jijibora set index