A coordinated proposal for BIC and IOA.
Prepared for 54AI and its stakeholders.
Internal review · Source-backed draft · Not a final offer
Proposal navigator54AI BIC & IOA Proposal Navigator
A coordinated proposal for BIC and IOA.
Prepared for 54AI and its stakeholders
Prepared by Francis, Keza Studio
9 October 2026 · Draft v1.0
Internal Keza review preview. Source-backed draft, not a client-sent final offer. Reported build states, final implementation scope and proposed terms require verification and agreement.
Strengthen Building Insurance Compliance (BIC) and the Intelligent Operations Assistant (IOA), preserve useful existing work and prepare both for controlled commercial deployment. Shared engineering standards support separate product backlogs, acceptance tests and launch decisions.
Source / Combined proposal §§1–2; BIC and IOA product overviews
Reconcile the deployed BIC build, its six NIIRA modules and IOA’s module inventory before fixing implementation scope.
Correct IOA’s claims and pricing defects, secure workflows and data, and prove tenant isolation.
Complete production integrations, performance tests, independent security evidence and product-specific handover.
The supplied documents now inform this draft. Reported completion is not independently verified; launch remains conditional on agreed tests, production dependencies and written approval.
Two product-specific delivery paths share engineering standards and governance, never merged data or authorisation.
Source / Combined proposal §§1, 3, 8–9; hardening scopes
Building Insurance Compliance connects property owners, state teams, field officers, insurers and subscribers. Verify the compliance journey and six NIIRA modules, activate payments and notifications, and test isolation for 36 states plus the FCT. Reported baseline: 29 active workflows and 9 or more Baserow tables.
Intelligent Operations Assistant supports claims, underwriting, distribution and reporting. Resolve eleven known defects, unify pricing, restore BVN verification and establish secure multi-tenant operation. Reported baseline: 42 or more workflows and 16 or more tables. IOA remains an overlay on insurer systems.
Separate BIC and IOA backlogs, owners, acceptance evidence and launch decisions. Apply common release, security, monitoring and recovery standards once, then configure and test for each product.
BIC’s NIIRA status conflicts between records. IOA describes 32 modules in nine sections but lists 33 entries in ten sections. Phase 0 reconciles both. Mango Cover’s relationship is investigated only; its development is excluded.
Phase 0 covers both products over approximately 7 to 10 working days after the required access is available. Inspect running systems, not demonstrations alone.
Source / Combined proposal §2; BIC and IOA hardening scopes, verification workstream
54AI leads demonstrations using Keza-selected test cases. Record deployed, incomplete, blocked and unverified functionality. Check BIC’s correct repository and final deployment; distinguish test-mode payments from live money.
Reconcile BIC core, NIIRA and revenue registers; compare IOA with the promotions deck and verify claim-value routing and underwriting permissions. Review repositories, active and inactive workflows, schemas, integrations and prior tests.
Assess n8n and Baserow throughput, tenancy, licences, backups and deployment options. Agree year-one volumes, concurrency, provider quotas, retention, datasets and launch dependencies.
Produce a verified module register with evidence and owners, prioritised defect and risk register, architecture/capacity decision and implementation schedule covering scope, exclusions, acceptance, resourcing and milestones.
Review findings with 54AI. If the build materially differs, present additional work, a reduced first release or revised pricing before delivery. No undefined rebuild or additional chargeable work begins without agreement.
Verification alone is the initial commitment. Its completed outputs remain useful if 54AI stops or chooses another partner. Implementation needs a separate signed scope and price agreement.
The shared hardening scopes and combined proposal provide the working detail below. Phase 0 confirms what exists; the verified register and signed implementation schedule govern final deliverables.
Source / Combined proposal §§3–10, 17–18; BIC/IOA hardening scopes; BIC-01–38 and IOA-01–40 user stories
Verify and harden alert → property identification → identity check → insurer selection → payment → Compliance Token. Cover state/revenue dashboards, mobile-browser field enforcement, insurer onboarding, policy ingestion, subscriber entitlements/API keys, renewal and expiry. Random allocation and land-charge entry points require confirmation.
Claims SLA Monitor, Pre-Permit Certificate, Energy Facility Compliance, Legal Conflict Detector, REIT Portfolio Tracker and Government Properties. Test deadlines, warning rules, QR issuance, scoring, attribution, alerts, AI failure and human review. Absent substantive modules require a scope/fee revision.
Activate live Paystack and penalty collection after bank/merchant access is available; verify approved revenue allocations, authenticated webhooks, duplicate suppression, refunds and settlement. Prove daily reconciliation with zero unexplained discrepancy. Activate email/SMS with retries and delivery logs; keep deferred Analytics Intelligence inactive.
Persist claim amount; prevent false submission success; display uploaded photos; restore BVN; consolidate duplicate pricing; replace placeholder rates; persist model confidence; expose claims audit history; fix silent logging; investigate unexplained underwriting rows; handle invalid-email failures. Each fix needs regression evidence.
Harden foundation/roles, claims, underwriting, customer and broker journeys, existing billing/commission, product aggregation, analytics, reporting, retention/consent, AI-Copilot and API keys. One pricing service uses 54AI’s reviewed rates across Property, Health, Life, Liability and Commercial. Dojah or one approved BVN fallback requires production access.
Backfill only from reliable source records; document unrecoverable values. Missing claim amounts must not become zero for straight-through processing. 54AI approves repair scripts, thresholds, underwriting permissions and changes to decision behaviour.
Protect reads, writes, APIs, files, exports, scheduled jobs and AI calls with tenant-context checks. BIC targets 37 state/FCT tenants; IOA’s exact organisation count and concurrent workload are agreed in Phase 0. Validate n8n/Baserow capacity and licences. Major migration, orchestration replacement or rewrite requires separate approval.
Separate development, staging and production; version application, workflows, schemas and prompts together. Confirm durable writes before success, with safe retries and traceable execution IDs. Maintain rollback procedures, monitoring, owned alerts and a demonstrated staging restore. Recovery objectives and backup frequency are agreed in verification.
Audit secrets and history, validate reported incident fixes, scan dependencies, manage credentials and rotation, coordinate independent penetration testing and remediate Critical/High findings. BIC requires a CREST-certified firm and licence audit. Record model/prompt versions, human review and safe provider failure. Prepare sandbox/data-flow evidence and update IOA’s ISO 27001-aligned material.
Native apps/USSD; live GIS and NIID; new insurer/government integrations; Mango Cover development; deferred analytics; IOA premium collection/core policy administration; actuarial analysis; legal opinions, certification and regulator approval; bank opening/state agreements; major rewrites or migration unless expressly added.
No claim of completed hardening or certified readiness is made. Scope changes, missing modules and unbuilt integrations require written impact assessment and agreement.
Deliver incrementally within product-specific milestones, with written approval at each gate and visible evidence throughout.
Source / Combined proposal §11; vendor questionnaire, delivery practices
Verified registers, architecture assessment, load profile and signed implementation scope.
Environments, permissions, managed secrets, release process and priority data-integrity controls approved.
BIC core and NIIRA fixes; IOA defects, pricing and identity work accepted through demonstrations.
Production integrations, isolation, load tests, live reconciliation and independent security testing.
Retest, product UAT, technical packs, controlled cutover, runbooks and knowledge transfer.
Weekly demonstrations and written updates show completed work, blockers, decisions and forecast dates. Named roles and committed capacity are recorded at the implementation gate; this estimate does not imply several full-time specialists throughout.
The planning window includes verification and assumes timely access, decisions and production dependencies. Overlapping phases are estimates, not committed calendar dates.
Source / Combined proposal §11 and §13
Subject to verification, dependencies and approvals. No guaranteed date.
Approximately 7 to 10 working days after required access is available, within the proposed weeks 1–2 window.
Foundations weeks 3–5; product hardening weeks 5–10; integration/scale weeks 9–14; acceptance/handover weeks 14–18. Confirm the calendar after Phase 0.
BIC payments can move earlier if accounts are ready. Continue independent work if one product is delayed. Revise affected gates and agree any remobilisation cost in advance.
Routine decisions are proposed within two working days. UAT is proposed within five working days of a milestone submission. Both are draft working arrangements requiring agreement.
The combined proposal assigns the responsibilities below for review. No account provision, rule approval or third-party delivery is treated as Keza-controlled merely because its integration is in scope.
Source / Combined proposal §16; open questions in both hardening scopes
| Record | Proposed responsibility / decision | Status |
|---|---|---|
| Keza Studio | Technical verification, agreed implementation, test evidence, independent-test coordination, in-scope remediation, documentation and handover. | Proposed owner |
| Named 54AI approver | Scope/commercial decisions, access, priorities, approved content, UAT participation and written gate approvals. | Approver to confirm |
| 54AI insurance advisers | Validate NIIRA/insurance rules, clock start/day-count/rounding, thresholds, permissions, reports and decisioning changes. | Written rule approval |
| 54AI actuarial and data owners | Reviewed rates, approved data repair, retention decisions, test data and permission for live-data handling. | Inputs required |
| 54AI operations and commercial team | Nigerian bank account, Paystack activation, production email/SMS, BVN access, state/partner agreements, test transaction funding and post-launch ownership. | External dependencies |
| Independent specialists | Authorised penetration testing and retest; separately commissioned legal, regulatory or certification work. | Supplier to appoint |
| Access and missing source material | Scoped repository, n8n, Baserow and deployment access; earlier BIC inventories/BDRs, IOA promotions deck, current issues, ISO/sandbox material and representative test accounts. Share secrets only through an agreed secure method. | Still required |
| Open business decisions | Resolve NIIRA build status, final BIC deployment, live versus test payments, insurer-allocation/partner rules, IOA underwriter permissions, missing-value handling, year-one volumes and approved provider fallback. | Pending verification |
| Risk and change control | Missing modules or capacity gaps: benchmark and agree reduced release or extra scope before fixed pricing. Dependency delays: record owner/date and affected gate. Irrecoverable data: report limitations, never invent values. | Decision record pending |
These are proposed responsibilities, not a record of accepted obligations. Local review notes capture discussion only; no agreed decision is automatically inferred from them.
Source-backed targets define the proposed evidence for each platform. Datasets, measurement points, workload and latency percentiles are agreed during verification; none is claimed as achieved.
Source / Combined proposal §§12–13; acceptance tables in both hardening scopes
| Workstream | Proposed target and evidence | Status |
|---|---|---|
| BIC / Compliance journey | Under five minutes from the agreed start to Compliance Token, including BVN and payment; record user/provider timing on representative devices. | Target to prove |
| BIC / State provisioning and national tenancy | New state under 15 minutes from approved inputs; 36 states plus FCT isolated across records, APIs, files, reports and background work. | Target to prove |
| BIC / Verification API | Under three seconds at the agreed load and percentile, with request/error rates and dataset size recorded. | Target to prove |
| BIC / Revenue and notifications | Controlled live transactions reconcile with zero unexplained discrepancy; scheduling/exceptions recorded. Live email/SMS evidence with retries and failure logs. | Target to prove |
| BIC / NIIRA and release evidence | All six verified modules pass approved cases and adviser-approved rules. No open Critical/High findings; mandatory blockers closed; technical pack, licence report, runbooks and restore evidence. | Target to prove |
| IOA / Claim routing and durable saves | First routing decision under 30 seconds at agreed load/percentile. Accepted claims persist amount/fields and process once; failed writes never display success. | Target to prove |
| IOA / Evidence, audit, pricing and identity | Authorised photo/history access; saved confidence and override reasons; one pricing implementation matches reviewed rates across five lines; production Dojah or approved fallback handles safe failure. | Target to prove |
| IOA / Scale and isolation | Meet the exact organisation count, concurrency and throughput agreed in Phase 0. No cross-tenant access through screens, APIs, files, reports, keys, workflow jobs or AI. | Target to prove |
| IOA / Known issues and security | All eleven documented issues resolved; additional issues closed or expressly deferred. No open Critical/High findings or mandatory launch blockers; independent report and retest required. | Target to prove |
| IOA / Operational objectives | 99.9% availability and 48-hour confirmed Critical-vulnerability remediation are objectives, not an unconditional SLA. Agree monitoring boundary, period, exclusions, support and escalation owner; proposed 30-day monitored operating period. | Target to prove |
| Both / UAT and release approval | 54AI runs agreed UAT within a proposed five working days and provides written acceptance or specific defects. Keza corrects in-scope failures and resubmits. Silence is not go-live approval; partial acceptance never waives mandatory blockers. | Written acceptance required |
Independent evidence supports technical review, not regulatory authorisation, legal enforceability or ISO certification. Live dependency tests cannot be replaced by test-mode evidence.
The provisional programme recommendation is £32,000. Only verification is the initial commitment; implementation remains conditional on verified scope and a separate fixed-fee agreement.
Source / Combined proposal §§14–15
Budget for discussion, not an accepted offer
£2,500 fixed phase, included in the total and paid before work starts. 54AI may stop after receiving completed verification outputs.
£29,500 assumes the stated modules exist and can be strengthened without major replacement. Confirm scope, capacity, milestones and fixed fee after Phase 0.
| Item / basis | Proposed amount |
|---|---|
| Verification / both products | £2,500 |
| Shared engineering, security and infrastructure | £6,000 |
| BIC hardening and production integration | £10,000 |
| IOA defects, pricing, identity and hardening | £10,000 |
| Final assurance, documentation and handover | £3,500 |
Combined budget allocation, not standalone project quotations. Total £32,000; implementation allocations remain provisional.
| Item / basis | Proposed amount |
|---|---|
| Verification / before commencement | £2,500 |
| Implementation mobilisation / 30% | £8,850 |
| Accepted product hardening / 30% | £8,850 |
| Accepted integration and assurance / 25% | £7,375 |
| Final acceptance and handover / 15% | £4,425 |
Implementation amounts apply only if the £29,500 estimate is confirmed. Proposed invoices due within five working days; verification and mobilisation before work. Final payment follows acceptance and precedes release/handover of unpaid deliverables under the agreed contract.
| Item / basis | Proposed amount |
|---|---|
| Independent test and retest / both platforms | £4,000–£8,000 one-off |
| Cloud, data, workflow and monitoring / before usage | £400–£1,200 per month |
| AI, BVN, email and SMS | Usage-based; forecast in Phase 0 |
| Licences, specialists and financial test charges | Separately approved and quoted |
Unverified planning assumptions, not supplier quotes or caps. Professional delivery plus independent testing suggests £36,000–£40,000 one-off, excluding tax, other external fees and recurring operation. 54AI owns/pays accounts directly where practical; agreed procurement is passed through at cost.
| Item / basis | Proposed amount |
|---|---|
| Platform Care / up to eight engineering hours | £650 per month |
| Fractional Technical Leadership / up to two days | £1,250 per month |
| Both services, if selected | £1,900 per month |
New engagement recommendations, not mandatory commitments. Monthly in advance, rolling with 30 days’ notice; unused capacity does not roll over. Additional work is quoted first. Business-hours coverage and exclusions are in Ownership / support.
The source proposes validity for 30 calendar days from 9 October 2026. Start date and delivery capacity require agreement when the relevant phase is commissioned. No capacity reservation fee, revenue share or compulsory retainer.
Excluding VAT where applicable and third-party costs. This is a proposed budget, not an accepted offer. The uploaded proposal’s payment/support terms below remain subject to agreement.
The combined proposal and questionnaire supply proposed ownership, warranty and support terms. Final liability, confidentiality, termination and contractual provisions remain for the services agreement.
Source / Combined proposal §§15, 17; vendor questionnaire §§1, 3
54AI retains its existing code, data, accounts and infrastructure. Keza receives scoped access. Tested milestone changes are released from controlled branches after corresponding payment, with agreed progress and commit-history visibility.
Project-output ownership is subject to signed terms and payment for the relevant work. Pre-existing Keza tools/methods and third-party/open-source licences retain their respective rights. The source’s “554AI” recipient typo needs correction before agreement.
Proposed from each platform’s signed production release for reproducible defects in Keza-delivered work against accepted scope, during UK business hours. Excludes new functionality, rule changes, third-party outages, misuse and changes by others; not an ongoing incident service.
Platform Care: up to eight engineering hours/month. Fractional Technical Leadership: up to two dedicated days/month. Rolling optional services, monthly in advance, 30 days’ notice; unused capacity does not roll over. Fees are set out in Investment.
Proposed support Monday–Friday, 09:00–17:00 Europe/London, excluding UK public holidays. Guaranteed response times, service credits or 24-hour coverage need a separate appropriately staffed agreement.
Source/workflow changes, schemas, configuration, setup, architecture decisions, tests, security/licence evidence, backup/restore, deployment/rollback, incident procedures and limitations. Two recorded knowledge-transfer sessions; an outside developer tests setup instructions.
These are proposed terms supplied in the documents, not a signed support or IP agreement. No compulsory retainer, reservation fee or revenue share is proposed.
This navigator summarises the files you shared. The working detail is available for internal review and print; the uploaded documents do not establish independently verified product status.
Source / Uploaded combined proposal, hardening scopes, product overviews, stories and questionnaire
54AI BIC and IOA Enterprise Hardening Proposal, 9 October 2026, version 1.0. Main source for delivery, acceptance, commercial schedule, responsibilities, exclusions and proposed ownership/support terms.
BIC and IOA hardening scopes, product overviews and user journeys/stories. Coverage spans BIC-01–38 and IOA-01–40. Duplicate BIC scope uploads are treated as one source, not additional requirements.
Keza’s responses support delivery practices, credential handling, client visibility and continuity. They do not replace the final services agreement.
Underlying BIC BDR v3.0 (BDR-54AI-BIC-2026-003), earlier BIC module records and IOA BDR v2.0 (BDR-54AI-IOA-2026-002), promotions deck and live system evidence remain to be supplied/verified. No external retrieval has been performed.
Resolve contradictory module counts/build statuses, missing business decisions and the “554AI” ownership typo. Source summaries are not proof of completion. No confidential source links or downloads are exposed.
Print exports the same source-backed internal draft, including provisional prices, proposed terms and unresolved decisions. Nothing has been published, emailed or signed.
Review the source-backed draft, settle open questions and discuss commissioning verification through a separate services schedule. Navigator actions record local notes only.
Source / Combined proposal §17, approval and next step
Confirm exclusions, dependencies, advisers, payment/support recommendations and corrections needed before any client-sent proposal.
Agree authorised access and representative cases; identify the approver, test participants, missing source material and production dependency owners.
Review verified registers and capacity decisions, then separately approve the implementation scope, fee and acceptance methods before delivery begins.
Feedback is device-only. Recording a note is not authorising a phase, sending a message or signing an agreement. Live AI and external-source retrieval remain unconnected.