← Davar Church App

System Architecture

Verified September 14, 2026 against the iOS app, Member Web, Davar AI, weekly pipeline, and production read-backs. This page distinguishes public, authenticated, local-only, automated, and implemented-but-not-active paths.

Current apps

iPhone / iPad public 1.19 build 238; App Review waiting and internal TestFlight 1.20 build 248 · Apple TV 1.10 build 107 · Android 1.20 Preview versionCode 21

Current AI

Open WebUI 0.11.0 · seven Knowledge collections attached to three models · five answer canaries and four required Davar corpora guarded daily

Focused recovery after a completed full UI suite: Diagnose every failure. When every failure is in test lookup, synchronization, fixtures, or assertions, product source is unchanged, the affected focused tests retain the exact production controls and downstream assertions, and independent review approves, the original full coverage plus focused passes closes the gate without another full run. An incomplete run, unexplained failure, missing runtime prerequisite, product failure, or product-source correction still requires a complete rerun.

1. Overview

Davar Web at www2.davarkg.com is the source of official public Church information. Blogger is the source of the Japan Branch Blog and original Verse Card posts. Member Web runs the WordPress app API, collects approved updates, builds the Home snapshot, stores Church media and Verse Cards, and proxies Bible AI. Davar AI stores searchable Knowledge and performs retrieval before answer generation.

Main paths: Davar Web or Blogger → Member Web → Davar App for public content. Bible AI continues from Member Web → Davar AI → selected answer model → server-side grounding check → Davar App. The app never signs in directly to Dropbox, Open WebUI, or the AI host.

2. Code-verified API and transport

PathAuthenticationEndpoints or implementationFailure behavior
Public readsNo member tokenGET /app/home, /newsletter-text, /media-series, /content, /photos, and /memory-verse-cardsUse the stored Home snapshot, last valid menu document, built-in content, or an empty optional view as appropriate
Member featuresPer-device token issued from the shared Church passwordGET /app/config, POST /app/chat, and POST /app/logout401 requires sign-in; an ungrounded Davar-specific answer is discarded and returns 503
Purpose-limited changesSeparate contribution or administrator sessionMedia contribution, Verse Card/Blogger publishing, announcement administration, orders/recovery, and room assignmentsNever reuse the Bible AI member token; reject invalid authority or inconsistent mutations
Network originTLSPrimary https://davar.jly.me; fallback https://d.cblh.usOnly GET/HEAD retry the alternate origin, and only for DNS/host-connect failures. POST/PATCH/DELETE are not replayed

For Image of God in iOS 1.20 build 248 and later, the authorized catalog identifies the protected package by its SHA-256 revision. Opening Bible and pulling the Continuous reader refreshes only a changed revision, validates the complete package, and saves it atomically. Network, validation, or persistence failure retains the last valid device cache. Server Markdown owns headings, Scripture quotations, indentation, and strong emphasis without book-specific page rules in the app.

/app/content is capped at 512 KiB and schema v1: 20 menu groups × 20 items, 50 pages, 100 blocks per page, and 100 announcements. Server-authored links must use HTTPS, default/443, no embedded credentials, and a subdomain of davarkg.com, cblh.us, jly.me, or davar.org. ETag revalidation prevents an invalid fresh document from replacing the last valid cache; the built-in document is the final fallback.

Implemented does not mean active: current iOS uses shared-password sign-in and a per-device token. The next iOS update places User Setup at the top of Settings and marks it complete only when this sign-in and at least one branch are present. The password itself is never stored; only the issued per-device token is protected in Keychain. Personal-account/Sign in with Apple server code is not the current iOS default path. Ollama is manually selected, and weekly YouTube upload exists but defaults off; neither is an automatic fallback or publication step.

3. Bundled Bible data

Bible reading does not fetch text from Member Web or a third-party Bible API at runtime. The app reads the bundled, read-only DavarBible.sqlite: Japanese Kougo-yaku, KJV, WLC Hebrew Old Testament, Delitzsch Hebrew New Testament translation, Swete Septuagint, Robinson-Pierpont Greek New Testament, WEB, Strong's tagging and lexicons, verse-number alignment, commentaries, TSK cross references, and Gospel parallels.

Highlights, notes, and search history remain on the device and are not cloud-synchronized. The Sources & Licenses screen may open public attribution links after a user taps them. Those providers are build-time data sources or references, not automatic runtime synchronization.

4. Content updates

Member Web refreshes approved Davar Web posts, pages, events, newsletters—including youth.davarkg.com—Church School information, and the public Japanese and English Store product feeds approximately every six hours. GET /app/home returns the saved snapshot and never re-crawls external sites during a user request. Section failures are recorded in sectionErrors.

Routine menu, page, and Inbox changes use a fixed declarative schema and do not require an app rebuild. Member Web reads the Blogger feed once and separates the exact みことばカード label from ordinary branch articles. For each group it keeps every item from the previous seven days plus the newest item for each branch label. The selected card permalinks enter the Home snapshot, where iOS 1.20 build 248 and later join them to normalized gallery sourceURL values. Pasadena (Headquarters) remains a fixed non-Blogger branch and never causes a synthetic post. Website updates retain their existing deduplication, newest-first order, and 16-item cap after removing items older than 31 days.

Cornelius Fellowship: Member Web places the allow-listed corneliusFellowship built-in destination immediately below Live Streaming in Media. The updated iOS app maps that identifier to the fixed https://messages.davarkg.com page and opens it in-app with loading, reload, pull-to-refresh, and failure/retry states. An app update is required for this new built-in menu item.

5. Church Photos & Videos

The permanent gallery is unscoped. JBS and SBS entries use server-owned event tags. Contributor endpoints cannot choose arbitrary tags, and media rows plus tags are committed atomically. Public slideshows need no Bible AI sign-in; the full album and contribution use a separate session; original/bulk download and administration are administrator-only.

Member Web can import user-confirmed media from a public iCloud Photos, OneDrive, Amazon Photos, Dropbox Transfer, or Dropbox shared-folder URL. Login- or password-protected shares are rejected. Only current clients explicitly requesting publicationMode=immediate after production activation create Public rows immediately; older or unknown clients remain pending/Private.

Upload batches are durable and bounded: the client queues the whole selection, retries eligible failures only after the first pass, and reports only remaining failures. Closing the sheet does not cancel already queued work. The internal 1.18 viewer hides video chrome after two idle seconds and advances deterministically after deletion.

6. Blogger Verse Card synchronization

The recurring importer traverses every page of the exact Blogger みことばカード label. The authenticated app form also acts as a Blogger publishing form: every submitted post is created on davarjp.blogspot.com, while the app gallery projects only posts whose current labels contain the exact みことばカード value.

  1. Compare every post with public gallery sourceURL and deletedSourceHashes values before authentication, download, or mutation.
  2. If current, exit without obtaining an upload session. If new sources exist, back up the exact table and image directory and rehearse restoration first.
  3. Retain the exact downloaded JPEG/PNG/WebP bytes for future printing. Create a separate PNG no larger than 420 × 420 for the list, and upload both images with the original source URL and Blogger publication date.
  4. Member Web returns the canonical newest-first sequence using the Blogger publication date, or the registration date for a manual card. The app inserts a year heading when that effective year changes, uses the derivative in the list, and prefers the original after a card is opened.
  5. Member Web independently deduplicates source and content. A tombstoned source returns HTTP 409 mikotoba_card_deleted; a failed tombstone write stops deletion with HTTP 503.
  6. Rerun the complete comparison and require zero pending sources plus HTTP 200 for every imported image.

For app-created posts, Member Web persists the local image and returns upload completion before eventual Blogger image ingestion finishes. It creates the canonical Blogger post immediately with the primary JLY image, uses paced Mail-to-Blogger only to obtain Blogger-owned image storage, then patches the same post ID/permalink and removes the staging draft after verification. Title, comment, multiple labels, rotation/image replacement, and deletion synchronize for the dedicated app author. Label reconciliation runs hourly. Removing the gallery label hides the post from the app without stopping image replacement; further edits can be made in Blogger.

7. Weekly pipeline

The scheduled orchestrator requires the current four-file set: Japanese and English sermon-summary DOCX plus Japanese and English bulletin PDF. The underlying pipeline can process individual PDF/DOCX inputs, but the weekly completion gate verifies all four expected files.

Member Web owns readable bulletin-text extraction using pdftotext with OCR fallback, and the app consumes the resulting API payload. Explicit blocks for worship-through-reports, the weekly memory verse, announcements, the following schedule, and source page 3 sermon summary are recorded as the next structured-text refinement; they are not claimed as part of build 198.

English narration uses AWS Polly Ruth long-form; Japanese uses Takumi neural, with speech marks produced through S3 task mode. Local ffmpeg creates MP4, SRT, and VTT outputs for Dropbox and Member Web. A Dropbox-only Davar AI collector normalizes the four sources and attaches new or changed content to davar-sermons. YouTube upload is optional and off by default.

8. Bible AI retrieval and grounding

Open WebUI performs local hybrid search and reranking. Production runtime values come from webui.db PersistentConfig—not container environment variables alone. The verified values are BAAI/bge-m3, hybrid search with BM25 weight 0.5, retrieval top-k 8, BAAI/bge-reranker-v2-m3, reranked top-k 6, and chunk 800/overlap 100.

Three models are attached to seven Knowledge collections: bible-web, bible-kjv, bible-kougo, davar-sermons, davar-info, davar-web, and davar-archive. The answer-path guard separately requires the four Davar corpora: sermons, info, web, and archive. commentary appears in a daily count table but is not attached to the current three models.

Davar-grounded answer

Branch/HQ facts, past seminars, and Davar-specific teaching, interpretation, sermon, belief, or stance require a question-relevant approved Davar source and excerpt. Otherwise the generated answer is discarded and HTTP 503 is returned.

General answer

Ordinary Bible explanation remains available with a server-owned label saying it has not been verified as Davar-specific teaching.

The server strips spoofed reserved labels, keeps inline [N] citations, returns at most five supporting excerpts, and sends at most the six most recent history entries. Empty or label-only output returns HTTP 502. Only selected retrieval chunks—not the full Knowledge database—are sent through LiteLLM to Claude. Ollama is a manual local model choice, not automatic failover.

9. Daily collection and monitoring

The 02:00 America/Los_Angeles job first runs the answer-path guard, then signs in to Open WebUI for collection. It runs ten collectors in four groups, regenerates three deterministic indexes, archives prior Web versions, analyzes aggregate question demand, and sends the daily report. Collector errors are non-fatal so later reporting still runs; therefore a final done is not proof that every collector passed.

The guard checks three model settings, five live canaries, and four required Davar corpora. Automatic repair is limited to the known function_calling=legacy drift after backup and is followed by read-back or rollback; missing Knowledge and general failures are not auto-repaired. The September 3 production read-back was healthy: 3/3 models, 5/5 canaries, 4/4 required corpora, zero repairs, zero errors, and zero consecutive failures.

10. External integration register

Reconciled September 3, 2026 against Davar App, Member Web, Davar AI, the weekly pipeline, and distribution scripts. Automated exchange and user-opened links are intentionally distinguished.

External integrationDirection and purposeDataFailure boundary
Davar Web and Church-operated sites
davarkg.com, www2.davarkg.com, youth.davarkg.com, davar.org, junasai.com, www2.junasai.com, and verified ministry sites
Periodic Member Web and Davar AI collectionPublic posts, pages, events, newsletters, Church School, official informationRecord section failures; never present unverified content as a new fact
Blogger / Blogspot
davarjp.blogspot.com
blogger.googleusercontent.com
Japan Branch Blog import plus authenticated app post create/edit/delete and image-storage replacementPublic metadata, title/comment, labels, publication date, original URL, and exact public imageDedicated-author ownership, immutable marker, exact post ID, allowed hosts, sourceURL, tombstones, original hash, paced mail ingestion, and verified read-back
Dropbox API / shared folderWeekly input/output and Davar AI collectorJA/EN summaries, bulletins, MP4/SRTVerify four inputs, hashes, URLs, and Knowledge registration; no direct app connection
iCloud Photos / OneDrive / Amazon Photos / Dropbox Transfer / shared folderServer-side import from a user-supplied public sharePre-selection manifest and confirmed public mediaPublic HTTPS only; reject login/password shares
YouTubeApp playback/RSS and Davar AI captions/catalogPublic feeds, playlists, metadata, available captionsFixed channels/playlists; missing captions are not success; weekly upload is optional/off
DuckDuckGo / Davar StoreBounded AI discovery and product collectionPublic results and allowed-domain descriptionsFive fixed queries plus identity/domain filters
AWS Polly / S3Weekly and guide narrationRuth long-form English, Takumi neural Japanese, audio, speech marksCredentials remain in execution environment; verify task result and conversion
Anthropic Claude APIBible AI answers and limited classification through LiteLLMQuestion, recent history, instructions, selected chunksNever full Knowledge; server rechecks Davar grounding and returns 503 if absent
APNs / FCMAdministrator-confirmed notifications or the daily 8:00 AM Los Angeles site-update digestDevice registration ID, two subscription choices, self-selected branch IDs for order announcements, and a minimal Inbox-reference/channel payloadCredentials stay server-side; administrator and site-update audiences are selected independently; scheduled order audiences are immutable and intersect the latest device affiliations; missing provider configuration returns 503
Vimeo / IBM VideoUser-requested external playbackPublic video URL and requestNot the Church-media original store
Cornelius Fellowship
messages.davarkg.com
Show the fixed public page in the in-app web screen only after the user selects it in MediaThe selected public HTTPS page and ordinary web requestNo background sync, Bible AI authentication, or Member Web content ingestion; the server sends an allow-listed built-in identifier and the app owns the exact URL
Facebook / Instagram / Apple Maps / Google Maps / Amazon and directory linksOpen only after user actionSelected public URLServer-authored links use four trusted root domains; built-in links are explicit app URLs
Zippopotam.us
api.zippopotam.us/us/{ZIP}
Approximate Member Web proximity from a US ZIPZIP only; latitude/longitude returnedNo name, street address, or member ID is sent; omit distance on failure
eKotoba, BibleEngine, OpenScriptures, Hebrew Wikisource, First1KGreek, Byzantine Majority Text, eBible.org, STEPBible, CrossWire, Bible ResearcherBuild-time bundled data and user-opened attribution linksPublic texts, tags, lexicons, commentary, cross references, mapping, source URLsNo runtime auto-sync; expose licenses and known gaps; never send user notes
Apple App Store / App Store ConnectBuilds, metadata, TestFlight, distributionSigned builds and store informationRuntime-independent; internal TestFlight and public release are separate read-back gates
Cloudflare edgePublic entry for software hostsTLS requests and cacheable public static contentTechnical docs remain private, no-store; verify hashes, not HTTP 200 alone
Operations and configured order emailLocal Postfix/sendmail reports and server-generated order deliveryAggregates, monitoring, actionable errors, or the bilingual submitted order sent to configured To/Cc recipientsNo credentials or full Knowledge; order recipients are administrator-configured and exact delivery/history is audited

In iOS 1.20 build 242 and later, Member Web collects new uploads from the two configured public YouTube Atom feeds and new products from the public Japanese and English Store APIs. Each daily announcement freezes the exact titles and URLs for updated pages, videos, Verse Cards, and Store products. Push carries only category counts and reference fields; details open the exact page, video, or product. The first valid YouTube or Store snapshot creates a quiet baseline, and failed fetches preserve the previous baseline. Store keeps an independent per-language high watermark made from the latest publication date and every URL on that date; any Store fetch error preserves both language baselines for that run. Instagram, Facebook and X ingestion awaits official API access. Notices without explicit expiry expire 30 days after publication; underlying orders are preserved.

Update rule: any changed service, domain, API, provider, notification path, or distribution target must update both language registers, affected diagrams, data boundaries, and the validator in the same commit.

11. Data boundaries