JJijibora Docs
docs.jijibora.online

S-01 — Overview (plain language)

If you've never heard of this platform: imagine one shared nervous system for a business. Instead of five disconnected apps (spreadsheets, email approvals, a booking tool, a records vault, a billing system), every fact about the business — who, what, who approved it, who gets paid — lives in one place, in a format anyone can look up. When something happens, the platform makes a record of it, and everyone the record concerns hears about it and can prove what happened later.

The three ideas beneath everything:

  1. A claim is a fact with an owner. "This insurance claim needs assessment" is a claim. "This team wants 200 blueprints" is a claim. "This seller owes this buyer a delivery" is a claim. Claims carry what stage they're at, who touched them, and the receipts that prove each step. Claims are the basic unit — not files, not rows.
  2. History is the product. Every change leaves a receipt (who, when, under which rule, what they saw). The platform never silently changes state: if a step is missing a signature or a rule, the system refuses — it does not invent or guess. That's why the code repeatedly says "fail closed" and "never invent": the product you buy is trustworthy audit trails, not vibes.
  3. Business rules live in one editable place, not inside code. Thresholds (how much money triggers extra approvals), service levels (how fast something must move), panels of who can do what — these are data packs (SOVEREIGN_LOOKUPS, packs in datasets/). Changing a number is a config change, not a code deploy. The code only knows how to read the pack and act on it.

What that buys in practice:

  • An adjuster is dispatched automatically when a claim arrives, and the record shows who accepted and when (time measured, not argued about).
  • A high-value claim can't be approved by one person — the system opens a quorum and records each approver.
  • If a step was skipped or forged, the audit file shows it immediately — weeks of manual audit assembly become an export.
  • The same engine runs insurance, government benefits, construction permits, or community tickets — the vertical is a configuration, not a different codebase. Five "lines of business" demo run on one plane.

What it does NOT do (by design):

  • It never invents a price, a saving, a signature, or a "live" status. If something can't be proven from real data, the system says so (honest empty states).
  • It doesn't act on a piloted claim without the customer turning on the knobs — proofs are built in a safe "Soft" mode first.
  • Money movement (invoicing, settlement) still goes through real billing adapters; this engine orchestrates the proof around it — see A-03.

For readers continuing: This is your entry point. The stakeholder track continues at S-02 Program, the glossary at S-03 Glossary, and the weekly retrospective at S-04 Week in Review. The developer and administrator tracks live at D-01 Architecture and A-01 Deploy Topology respectively. The master catalog indexing all documents is at COMPREHENSIVE_SYSTEM_CATALOG.md.