Resk product system

0. Delivery Audit and Designer Handover #

Read this first #

The assigned work is not all done. There is substantial merged implementation, but neither a merged PR nor a Completed Jira status proves that the full product or its acceptance criteria are complete. The designer can proceed with the product structure and journeys below; engineering must close the explicit contract and integration gaps alongside the redesign.

This revision supersedes the product structure on the previously published 24 August Intelligence redesign PRD. Its five Intelligence destinations remain useful within Intelligence, not as the entire Resk navigation. Operations owns deep business administration. Frontdesk sits within Growth. Hyper is an optional Operations till, not a fourth core product.

Sections 1-24 describe the required product, not a claim that every listed capability is deployed. This section records observed delivery on 6 September 2026. Section 25 is the current brief for Abdulbasit Bankole. Section 15.5 distinguishes existing APIs from the proposed product-versioned API structure.

The original four assignments #

Ownership is unchanged. This document does not transition Jira issues or assign new tickets. Completion should be reconciled against the remaining criteria below, not by erasing delivered work or treating old ticket labels as the final product structure.

Stephen: what is delivered and what remains #

PREPLINK-1014. Stephen's Intelligence PR 180 merged on 27 August. All eight operations under /operator/ui/v1 remain on the audited dev revision: context, Today, Work list/detail, work commands, Performance, Records and Connect. Documentation, an OpenAPI artifact, generated request types and tests exist. The facade reuses existing Operator execution paths rather than creating a second commerce engine.

Remaining acceptance work:

• Complete successful response schemas and generated screen-model types. The checked-in OpenAPI has eight operations but no successful response schemas; an operation-name map is not a full typed UI contract.
• Deliver genuinely different Restaurant service-readiness and Retail trading/stock models, including explicitly supported dual-module context. The current vertical resolver prefers Restaurant and defaults unknown businesses to Restaurant; Today uses the same generic health areas.
• Preserve actual source timestamps and stale status. A successful read stamped with the current time is not proof that the underlying business data is fresh.
• Filter advertised actions by the current actor and location authority. Coarse role-derived permissions must not be described as completed fine-grained authorization.
• Make Connect report the actual vertical owner and observed channel health. Restaurant-hardcoded booking/public-page metadata and deriving phone status from SMS health do not satisfy that contract.
• Capture the Retail stockout and Restaurant ingredient-shortage journeys through approval, canonical execution, read-back and durable receipt, including failure and cross-tenant/location negative cases.

PREPLINK-1017. Stephen's Frontdesk PR 298 merged on 27 August. Versioned controllers, entitlement and permission checks, customer/communication/Agent APIs, engagement/referral delegation, message-row deduplication, and settings concurrency/audit are present.

Remaining acceptance work:

• Replace or extend Today counts with the specified actionable queue: stable item ID, source, timestamps, urgency, due time, actor permissions, destination and permitted action.
• Establish and verify outbound delivery through the Frontdesk send path. The reviewed method writes a pending message row with hardcoded channel/provider values and returns; it does not itself send or enqueue delivery. A targeted source search did not establish a Frontdesk dispatcher. This is a gap in this path and its proof, not a claim that all existing Resk messaging is broken.
• Complete successful response schemas and generated response types. The committed spec lists 33 operations without successful response schemas.
• Return authorized, contextual booking/public-page destination or action contracts, not only availability and owning-service labels.
• Verify settings protection across knowledge, voice and phone, not only the implemented /agent/settings version conflict path.
• Prove enabled Restaurant/Retail and disabled/restricted-user journeys, message delivery outcomes, referral qualification/reward lifecycle and duplicate protection against the actual owning services.

Both original PRs had passing unit, build, security and repository live-integration checks. PR 298 also contains live Postgres verification of settings version conflicts, audit writes and deduplicated message rows. Testing exists; full facade, vertical and provider workflow acceptance remains open. This audit did not rerun backend suites against the dirty local service checkouts.

Dayo: what is delivered and what remains #

PREPLINK-1015. Dayo's frontend PR 786 added recursive API inventory, service-owner classification, an allowlist and an Intelligence import-boundary check. That is useful supporting work.

The main acceptance requirements remain outstanding:

• No frontend src consumer of /operator/ui/v1 exists on the audited dev revision. Current Operator requests still use legacy feed/cards/plans endpoints.
• The specified Intelligence screen route group and dedicated typed facade client have not been implemented. Existing Dashboard and Analytics still assemble shared and vertical responses in the browser.
• Complete the entitled shared shell, Restaurant/Retail screen fixtures, Work/Records pagination, approval commands, source/freshness states, compatibility routing and outcome analytics against the versioned contract.
• Finish inventory enforcement. On this audit, the check found 811 operations against a 757-operation baseline and failed. Its narrow import check targets an Intelligence directory that is not present, and it is not invoked by the checked-in CI workflows. Update coverage and review the drift before refreshing the baseline; do not merely increase the expected count.
• Provide the specified responsive, accessibility, permission, negative-state and real-journey evidence. Existing Operator repairs are not a substitute for this contract migration.

PREPLINK-1016. Dayo's PR 824 added the Frontdesk client, context/Today hooks and Growth integration. PR 825, PR 826 and PR 827 refined Growth navigation and overview behavior. These are real delivered changes, not just plans.

Remaining acceptance work:

• Migrate the intended capability flows, not only the overview. Only Frontdesk context and Today are currently consumed; most other client methods are unused and return any.
• Calls, Customers and Agent still use legacy clients. Agent assembles multiple responses in the browser. Reusing these workflows preserves behavior, but does not complete the stable Frontdesk integration requirement.
• Derive top-level Growth visibility from the authenticated product profile and actor capabilities. A module-view permission alone is not a Growth entitlement.
• Apply capability filtering consistently in navigation and content. The referral builder is capability-gated, but the tool directory/selectors still advertise Referrals when disabled.
• Use business timezone/locale explicitly and preserve destination, tenant and location through Growth-to-Operations handoffs.
• Prove call review, actual message reply, customer lookup, booking handoff, follow-up and Agent settings for enabled Restaurant/Retail, disabled businesses and restricted users. Include keyboard, focus, 200% zoom, partial failure and retries that reconcile the previous attempt before another write.

Current audit checks: 18 focused Growth access, contract and rollout tests passed; the separate API-inventory check failed as described above. No live customer communication or business write was performed by this audit.

Later work that must not be lost or misattributed #

• Frontend PR 828, delivered by Jonathan/Codex after Dayo's changes, restored Be Found / Take Demand / Bring Customers Back and retained Dayo's Frontdesk foundation. Its richer tools, scoped detail navigation, contract validation and rollout tests are part of the current baseline. The older Growth presentation remains a flag-off compatibility path.
• Frontend PR 829 added the Operations workspace. PR 830 repaired Operator/Operations nesting, repeated loading, selection and draft preservation, supplier navigation, access-loss behavior and responsive interactions.
• PR 830 is merged to dev at 2e2cbdc9e66e0a8dad59cd2c9107164549b452df. Its deployment succeeded. The release handover records 122 focused tests and a passing dashboard build, plus sampled Chrome verification. This is not a count of browser scenarios and not full Operations acceptance.
• Real-business stock, procurement, returns, payments and Operator execution acceptance remains pending. Fixture journeys do not settle these gates. Full hardware, offline, screen-reader and browser coverage is not established by the repair release.
• No application rollout or feature-flag targeting changes are made by this PRD update. The current rollout instruction remains dev activation for the verified Grill Labs tenant only, unless separately authorized. Exact flag targeting was not re-audited in this pass and must be reconfirmed before any further rollout. The other pilot profiles below are acceptance requirements, not authorization to enable those customers.

Related assignments, outside the four-ticket acceptance audit #

These were also found under Stephen and Dayo. Their code was checked for delivery presence, but their complete acceptance criteria were not re-audited here.

Completion rule and next handoff #

1. Stephen: close and publish the missing response schemas, vertical models, queue/delivery and capability semantics against the existing backend tickets; attach contract and workflow evidence. Do not rebuild already merged foundations.
2. Dayo: complete Intelligence facade consumption and Growth flow integration against the agreed schemas, while retaining the restored Growth grouping and Operations/Operator repairs.
3. Abdulbasit: design the complete three-product experience and state variants in section 25. Identify every requested field/action that still lacks a working contract; do not represent it as available solely because a mockup needs it.
4. Joint acceptance: review the actual browser journey against the approved design and contract, then confirm tenant permission, canonical write, provider result where relevant, and durable read-back evidence. A screenshot or green build alone cannot close the ticket.

This is a proposed handoff using the existing ownership, not a new assignment or schedule. No percentage-complete score is claimed because the remaining criteria differ materially in risk and scope.

1. Executive Summary #

Resk will be organised as three core customer products:

1. Resk Intelligence helps owners understand the business, speak to Operator, approve work and verify outcomes.
2. Resk Growth helps businesses get found, capture demand and bring customers back.
3. Resk Operations runs the operational system of record for restaurant and retail businesses, including orders, catalogue or menu, inventory, suppliers, purchasing, fulfilment, payments, reporting and access management.

Resk Operator is the business-wide operating layer across all three products. Its primary home is Intelligence, but that is not its scope boundary. Operator can read, analyse, draft, create, update, execute, monitor, retry, cancel, hand off and verify every action that the current tenant, actor permission, owning Resk API and connected provider support. This includes creating and administering referrals as well as Growth, Retail, Restaurant, payment, team, settings and connector work.

Hyper is not a fourth core product. Hyper remains the dedicated POS and till application inside Resk Operations. It is an optional execution channel for businesses that sell in person. Online-only businesses use Resk Intelligence, Resk Growth and the Dashboard-based Resk Operations workspace without ever needing Hyper.

The resulting product story is:

Growth brings demand in. Operations fulfils it. Intelligence sees the whole business and puts Operator to work. Hyper runs the till when a business sells in person.

This PRD is a product and architecture decision record. It does not authorise code changes, deployment, provider onboarding, customer activation or destructive route removal.

2. Final Product Decision #

2.1 Product count #

Resk has three core products, not four.

Hyper is a specialised application within Resk Operations:

Hyper may be sold or packaged as an add-on, but it must not create a fourth data model, fourth back office or fourth product architecture.

2.2 Product hierarchy #

Resk
├── Intelligence
│   ├── Today
│   ├── Operator
│   ├── Work
│   ├── Performance
│   ├── Records
│   └── Connect
├── Growth
│   ├── Be Found
│   ├── Take Demand
│   └── Bring Customers Back
└── Operations
    ├── Retail Operations
    ├── Restaurant Operations
    └── Hyper POS
        ├── Retail till
        └── Restaurant till where enabled

Operator crosses this hierarchy:

Operator home: Intelligence
Operator action scope: Intelligence + Growth + Operations + Connect
Execution authority: the canonical owning API for each action
Control: tenant permission + action capability + risk policy + approval
Completion: canonical read-back + durable receipt or explicit exception

2.3 Why Operations replaces POS at the core-product level #

The name POS excludes businesses that sell online, by phone, through marketplaces or through an existing third-party till. Resk already supports operational work that is broader than a checkout screen: catalogue, menu, online orders, reservations, inventory, suppliers, purchasing, fulfilment, customers, payments, returns, reports and team permissions.

Operations is therefore the correct core product. Hyper preserves the dedicated POS identity and remains optimised for in-person selling.

3. Problem Statement #

3.1 Original problem, 31 August baseline #

At the original planning baseline, Resk capabilities were distributed across Dashboard routes, Retail back-office routes, Hyper POS, restaurant workflows, customer engagement, offers, referrals, promo codes, SMS, phone AI, websites, SEO, reviews, reports and integration settings. Section 0 records subsequent delivery; this problem statement explains why the work was commissioned.

That structure exposed five problems:

1. Product ownership is unclear. Marketing, commerce, operational and intelligence capabilities appear beside each other without a stable outcome-based structure.
2. The retail back office is duplicated. The same Retail application is mounted beneath both Dashboard and POS, creating a second sidebar and making Hyper look like a full management platform rather than a till.
3. Online-only retailers are forced into POS language. They need products, orders, fulfilment, inventory and reports, but do not need a register, cash drawer, shifts or hardware.
4. Implemented screens are mistaken for completed operations. Inside Africa currently demonstrates live catalogue, stock movements and reports, while supplier, purchasing, stock-count, transfer and role workflows are present but unused or unproven.
5. Operator risks becoming another reporting layer. It must act through the canonical Restaurant, Retail, Growth, payment and connector APIs and preserve evidence, approval and verification.

3.2 Historical retail evidence #

The 31 August Chrome audit of an existing physical retailer found a working Hyper till, catalogue, stock movements and reports, alongside duplicate Dashboard/POS management navigation. Supplier, purchasing, stock-count, transfer and custom-role journeys were not demonstrated merely by the presence of their screens. Stock Activity and manual-adjustment concepts also needed separation.

This is dated discovery evidence, not a new production-state claim. Detailed tenant trading figures and record counts are intentionally omitted from this published PRD. The implementation since that audit is recorded separately in section 0.

The finding remains relevant: the platform has substantial operational breadth, but the presence of a route does not establish a complete, configured and accepted workflow.

3.3 User impact #

3.4 Business impact #

• Slower onboarding because hardware and till concepts appear to be prerequisites.
• Higher training and support cost caused by duplicated navigation and unclear terminology.
• Lower adoption because online-only and existing-POS customers cannot see a software-first path.
• Greater delivery risk because surface-level navigation can hide incomplete domain contracts.
• Weaker product positioning because Resk appears to be a collection of features rather than a connected operating system.

4. Product Principles #

1. Three products, one company context. Intelligence, Growth and Operations share identity, permissions, customer context and audit history without sharing ownership of every calculation.
2. Hyper is a till, not a back office. Barcode-to-cart and cart-quantity interactions target p95 below 200 ms on supported hardware, while the experience remains resilient and focused.
3. Dashboard is the canonical management surface. Owners and managers use one navigation system at app.resk.ai.
4. POS hardware is optional. A business can receive value before installing or replacing tills.
5. Vertical domains remain authoritative. Retail and Restaurant retain their own operational rules and APIs.
6. Operator operates across the whole business without replacing domain ownership. Intelligence is its home. Operator reads evidence, drafts and creates records, governs approval, executes supported actions through Growth, Retail, Restaurant, payment, settings and connector APIs, then verifies the canonical result.
7. Capabilities determine navigation. Online-only, POS-only and omnichannel businesses see only the workflows they can use.
8. Compatibility before removal. Existing routes, bookmarks and desktop workflows receive tested redirects or handoffs before old shells are retired.
9. Visible capability must match executable capability. Read-only, recommend, approval-required, executable and verifiable states are shown explicitly.
10. No completion claim without runtime proof. Code, deployment, tenant configuration, installed-client uptake and observed user outcome remain separate evidence layers.

5. Goals #

Every goal is measured at a named delivery gate. The timeframe is phase-gated rather than date-gated: a phase cannot advance until its target and evidence are satisfied.

6. Target Users and Business Profiles #

6.1 Primary user roles #

• Business owner
• General manager
• Marketing or growth manager
• Cashier or server
• Inventory and purchasing manager
• Fulfilment or kitchen team member
• Accountant or finance operator
• Resk support and implementation staff
• Resk Operator acting within granted permissions

6.2 Supported business profiles #

Online-only retail #

Uses Dashboard Operations for catalogue, online orders, fulfilment, inventory, suppliers, payments, returns, customers, reporting and settings. Uses Growth for website, SEO, discovery, reviews, campaigns and retention. Does not require Hyper.

Physical retail #

Uses Dashboard Operations for management and Hyper POS for register execution, cash management, local receipts, refunds, shifts, hardware and customer display.

Omnichannel retail #

Uses one catalogue, inventory ledger, customer model, payment model and order history across online and in-store channels. Hyper is enabled for physical locations.

Software-first restaurant #

Uses Growth for website, AI phone, bookings, ordering, customer engagement and reviews; Operations for menu, orders, reservations, delivery, inventory, suppliers and reporting; Intelligence for Today and Operator. It may retain an existing third-party POS through Connect.

Full Resk restaurant #

Uses all three products plus the enabled restaurant till, kitchen, printer, terminal, kiosk, handheld and customer-display capabilities.

6.3 Capability model #

Navigation and permissions derive from four dimensions:

• Product entitlement: Intelligence, Growth, Operations
• Vertical: Retail, Restaurant or supported service profile
• Sales channels: Online, in-person POS, phone, marketplace, kiosk, QR or delivery
• Actor permission: Owner, manager, marketing, cashier, inventory, fulfilment, finance or support

The user must never see a prominent control that the current tenant, connector or actor cannot use.

7. Resk Intelligence #

7.1 Positioning #

Resk Intelligence is where owners see what is happening, ask Resk what to do, approve the work and verify what changed. It is Operator's primary home, not the limit of what Operator can control.

Working copy: See what is happening. Ask Resk what to do. Approve the work. Verify the result.

7.2 Navigation #

Today #

The concise, prioritised business brief. It answers:

• What needs attention now?
• What demand, revenue, margin or service is at risk?
• What changed since the previous operating period?
• What is waiting for approval?
• What work completed or failed?
• What should the owner know before the next service period?

Today links to the canonical Growth, Operations, Work, Record or Connect context. It does not recreate the destination workflow.

Operator #

The first-class conversational and action workspace. Users can type, speak and attach screenshots, invoices, menus, stock sheets, voice notes and documents.

Every proposed action card includes:

• Finding and business impact
• Supporting evidence and source freshness
• Proposed action
• Affected customers, channel, location or business area
• Expected result
• Required permission and approval state
• Execution progress
• Read-back verification
• Durable receipt or exception record

Business-wide Operator mandate #

Operator must be capable of operating across the whole authorised business. It is not a reporting assistant and it is not restricted to Intelligence screens. When an action is available through a canonical Resk API or an executable connected-provider capability, Operator can perform it from the dedicated Operator workspace or from contextual Ask Resk.

"Everything doable" has a precise product meaning:

• Read and analyse: retrieve current records, compare periods, investigate exceptions and explain the source and freshness of the evidence.
• Draft and recommend: prepare content, campaigns, referrals, orders, purchase orders, adjustments, replies, settings or operational work for review.
• Create and update: create or edit canonical records through the owning API when the tenant and actor have permission.
• Execute and control: launch, publish, send, fulfil, receive, transfer, refund, retry, cancel or hand off when the action and risk policy permit it.
• Monitor and verify: follow asynchronous work, provider callbacks and domain state until canonical read-back proves the outcome or records an explicit exception.

It does not mean unrestricted superuser access, direct database writes or pretending an unsupported provider action succeeded.

Operator capability catalogue #

The action registry covers the following product scope. The catalogue is extensible, but every added action must declare the same ownership and governance fields.

Referral execution is an explicit first-class example. Subject to entitlement and permission, Operator can create or update the referral programme, create an individual referral or shareable code, identify the advocate and referred customer where known, apply qualification rules, monitor conversion, issue or reverse a reward through the canonical owner, and verify the resulting ledger and customer timeline.

Action registry contract #

Every Operator action must declare:

• Stable action identifier and version
• Owning product, service and canonical API
• Supported verbs and affected entity identifiers
• Required product entitlement, connector capability, actor permission and location scope
• Risk class and approval policy
• Input schema, human-readable preview and expected outcome
• Idempotency and retry behaviour
• Execution, asynchronous monitoring and cancellation behaviour
• Canonical read-back query
• Receipt, exception, reversal and human-recovery behaviour

Actions appear only when the registry says they are available for the current context. Missing backend support is shown as a product gap or human handoff, never as a working button.

Operator risk and approval classes #

Contextual Ask Resk #

Ask Resk is available from Intelligence, Growth and Operations pages and receives the current business, location, record and page context. It may call any action in the same business-wide registry. The dedicated Operator page remains the place for longer conversations, multi-step work, approvals, receipts and exceptions.

Work #

The durable queue for work created by Operator, staff, Growth, Operations and connected systems.

Supported lifecycle:

Detected → Proposed → Waiting for approval → Approved → Executing
        → Needs human action → Verified
        → Failed / Exception / Cancelled

Performance #

Connects metrics to actions and verified outcomes. It includes demand, sales, margin, repeat customers, campaigns, bookings, payments, inventory pressure, supplier performance and completed work.

Performance distinguishes observed correlation, attributed outcome and settled financial value.

Records #

Stores conversations, action cards, approvals, execution receipts, documents, communications, policy changes, failures and provenance.

Connect #

Shows each connected POS, payment, booking, delivery, accounting, messaging, ecommerce, inventory and supplier system with:

• Connection health and freshness
• System-of-record ownership
• Read, recommend, execute and verify capabilities
• Granted permissions
• Setup gaps and required human handoffs

7.3 Intelligence acceptance criteria #

• One stable business-context façade supplies Today, Work, Performance, Records and Connect.
• Browser pages do not recreate multi-service aggregation rules.
• Every action resolves to a canonical owning API and destination.
• Every in-scope supported action is represented in the Operator registry with capability, permission, risk, approval, idempotency, read-back and recovery metadata.
• Creating and administering referrals is executable from Operator when the canonical referral owner reports the required capability and the actor has permission.
• Operator can execute authorised actions across Growth, Retail Operations, Restaurant Operations, payments, team settings and Connect without being limited by its Intelligence navigation home.
• No action is labelled completed until post-execution read-back succeeds.
• Failed execution preserves evidence and an explicit recovery action that cannot repeat the write without confirmation.
• Ask Resk inherits the current customer, order, campaign, metric, connector or operational context.

8. Resk Growth #

8.1 Positioning #

Resk Growth helps businesses be found, capture demand and bring customers back without requiring Resk POS hardware.

Working copy: Be found. Take demand. Bring customers back.

8.2 Be Found #

Capabilities:

• Website and public pages
• Menus, catalogues and service pages
• Technical SEO and structured data
• Search Console and website performance
• Local listings and business-profile health
• Google review acquisition and response workflows
• Yelp and Trustpilot integrations where provider access supports the required action
• Content planning and publishing
• Local-discovery recommendations
• Search, listing, review and website performance

SEO implementation principles:

• Begin with owned-site audits, schema, crawlability, page quality, Search Console data and approval-controlled recommendations.
• Treat geo-seo-claude as an audit and schema reference, not production infrastructure.
• Treat open-seo as a reference for adapter-backed keyword, ranking, backlink and local-rank capabilities.
• Treat Agent-Reach as Operator research tooling, not a production crawler or customer data system.
• Provider-specific publishing requires confirmed API access, tenant consent and read-back verification.

8.3 Take Demand #

Capabilities:

• AI phone agent
• Call handling and missed-call recovery
• Bookings, reservations and deposits
• Online ordering
• Collection and delivery entry points
• Catering enquiries and conversion
• Payment links
• Offers and upsells
• Customer messages and service follow-up

Growth owns acquisition and conversion experiences. Operations owns the resulting canonical booking, order, payment and fulfilment records.

8.4 Bring Customers Back #

Capabilities:

• Customer profiles and timelines
• Audiences and customer groups
• Email and SMS
• Campaigns and automated follow-ups
• Offers and promotion creation
• Referrals
• Loyalty points and rewards
• Birthday, VIP, win-back and abandoned-order journeys
• Consent and channel preference management
• Campaign, repeat-order and retention performance

8.5 Engagement Studio #

Engagement Studio is a workspace within Growth. It contains campaigns, automations, email, SMS, audiences, templates, referrals, loyalty, rewards, offers, consent and results.

It is not a separate core product.

8.6 Growth ownership boundaries #

• Growth defines the audience, message, offer intent and channel schedule.
• Retail or Restaurant validates catalogue, menu, price, availability and order rules.
• Payment services validate payment links and settlement state.
• POS validates promotion or stored-value behaviour at checkout.
• An offer that behaves like money must use the appropriate tender and settlement model rather than a cosmetic promo-code implementation.
• Communications require recorded consent, suppression and delivery evidence.

8.7 Growth acceptance criteria #

• All Growth capabilities appear under one Growth product navigation.
• Referrals, loyalty, offers and campaigns are available across entitled verticals rather than appearing as retail-only concepts.
• Existing scattered routes redirect or deep-link into their canonical Growth destination.
• SEO recommendations identify evidence, affected pages, proposed change and verification method.
• Review integrations show whether Resk can read, draft, publish or only hand off.
• Growth-created orders, bookings and payments are visible in Operations without duplicate records.

9. Resk Operations #

9.1 Positioning #

Resk Operations is the canonical management product for commerce and day-to-day business execution.

Working copy: Run the work behind every sale.

Operations is delivered through the Dashboard. It is not a duplicate Hyper back office.

9.2 Shared operational capabilities #

• Orders and fulfilment
• Catalogue or menu management
• Pricing, tax and availability
• Inventory and stock locations
• Suppliers and purchasing
• Receiving, returns and adjustments
• Customers linked to operational records
• Payments, invoices, refunds and reconciliation
• Reports and exports
• Users, roles and settings
• Hardware and channel configuration where entitled

9.3 Retail Operations #

Retail Operations includes:

1. Catalogue setup and bulk editing

   • Products, variants, SKUs, barcodes, categories, brands, units, price, cost, tax, media and availability
   • Import, export and validation
   • A table-first bulk-edit workbook with a detail rail and explicit save state
   • Product and variant media separated clearly

2. Supplier management

   • Supplier identity, contacts, terms, tax, currencies, product mappings, balances and activity

3. Purchase orders

   • Draft, approval, submission, receiving, partial receiving, supplier invoice, payment, return and cancellation states

4. Stock ledger and adjustments

   • Immutable movement ledger
   • Separate manual adjustment documents for opening, recount, damage, expiry, loss and correction
   • Sales and reservations remain visible in Stock Activity but do not masquerade as manual adjustments

5. Variance investigation

   • Stock-take creation, scanning, expected-versus-counted comparison, value impact, evidence, approval and posting

6. Multi-location transfers

   • Draft, dispatch, in-transit, receive, discrepancy and cancel states
   • Locations use meaningful names and types such as shop, warehouse or stockroom

7. Reports

   • Sales, products, category, payment method, discounts, customers, suppliers, inventory, purchasing, accounting, shifts and channel performance
   • Reports distinguish transactions from tender uses and online from POS channels

8. Users, roles and settings

   • Owner, manager, cashier, inventory, fulfilment and finance access
   • Reusable roles and least-privilege permissions
   • Company, branding, regional, currency, receipts, pricing, numbering, payments, backup, updates and privacy settings

Retail Operations also owns online orders, returns, storefront fulfilment, delivery or collection status and operational customer service.

9.4 Restaurant Operations #

Restaurant Operations includes:

• Menu, modifiers, price, tax and availability
• Ingredients, recipes, yield and menu cost
• Inventory, stock counts, waste, expiry and ledger
• Suppliers, purchasing, receiving and supplier invoices
• Orders, tables, service areas, kitchen and fulfilment
• Reservations, waitlist, deposits, delivery and catering operations
• Cash sessions, payments, invoices, refunds and reconciliation
• Staff roles, settings and restaurant reports

Restaurant Service remains the canonical owner of restaurant commerce calculations and lifecycle rules.

9.5 Online-only Operations experience #

Online-only retailers see:

• Home
• Orders
• Fulfilment
• Products
• Inventory
• Suppliers and purchasing
• Customers
• Payments and returns
• Reports
• Website-commerce configuration
• Team and settings

They do not see:

• Register
• Counters
• Cash drawer or cash up
• Till shifts
• Customer display
• POS hardware
• Register setup
• End-of-day till controls

The two currently active online-only retail businesses must be resolved to exact tenant identifiers during rollout preparation and used as real pilot tenants. Their identities must not be invented in planning or test fixtures.

9.6 Operations acceptance criteria #

• Dashboard contains one navigation system with context-aware Operations sections.
• No nested Retail or Restaurant sidebar appears inside the global Dashboard sidebar.
• Online-only tenants see zero POS-specific navigation controls.
• Omnichannel tenants use the same products, customers, inventory and order truth across online and POS channels.
• The low-stock to supplier to draft purchase order to approval to receiving journey has read-back and receipt evidence.
• Stock Activity and manual Stock Adjustments are distinct and understandable.
• Roles explain their operational purpose and reflect actual POS and back-office access.

10. Hyper POS #

10.1 Positioning #

Hyper is the dedicated till application for in-person selling. It prioritises speed, touch targets, offline continuity, device integration and cashier confidence.

Working copy: Run every in-person sale.

10.2 Hyper home capabilities #

Hyper retains:

• Register
• Camera or barcode scanning
• Recent transaction history
• Drawer
• Refund
• Held sales
• Customer lookup
• Labels
• Send invoice
• Send quote
• Invoices
• Calculator
• End shift
• Customer display
• Refresh data
• Register setup
• Shortcuts and help

The current Sales Report tile becomes a narrow Shift Summary suitable for the active register. Full business reporting lives in Dashboard Operations.

10.3 Back-office removal and Dashboard handoff #

The Hyper Back Office tile is replaced with Open Dashboard.

Rules:

• Visible only to an owner or authorised manager.
• Hidden from cashiers without management access.
• Opens Dashboard in a separate browser tab, browser window or desktop secondary window.
• Preserves the active cart, cashier, counter, drawer and shift.
• Carries business and location context through server-managed session state rather than URL credentials.
• Reuses the authenticated session where permitted or returns the user to the requested destination after authentication.
• Shows a clear unavailable state when offline rather than navigating the till away.

10.4 Canonical route ownership #

• Hyper register and till routes remain at pos.resk.ai.
• Retail back-office routes are canonical at app.resk.ai/retail/* during the compatibility phase.
• Equivalent non-till routes under pos.resk.ai/retail/* redirect to the same relative path on app.resk.ai.
• Redirects preserve destination and tenant context and return only to allow-listed origins.
• Existing bookmarks receive compatibility redirects before the old shell is retired.

Examples:

pos.resk.ai/retail/dashboard  → app.resk.ai/retail/dashboard
pos.resk.ai/retail/catalog    → app.resk.ai/retail/catalog
pos.resk.ai/retail/suppliers  → app.resk.ai/retail/suppliers

10.5 Hyper acceptance criteria #

• No full back-office navigation renders inside Hyper.
• A cashier cannot reach management pages without the required permission.
• Opening Dashboard never clears or replaces the active till session.
• Browser, PWA and packaged desktop behaviours are verified separately.
• Hyper remains functional during a temporary Dashboard or internet outage within its supported offline scope.
• The active business, location, cashier, counter and sync state are always visible.

11. Cross-Product Ownership #

No new service is created solely to mirror this ownership table.

12. Dashboard Information Architecture #

12.1 Global navigation #

The Dashboard uses one global navigation system:

• Home
• Intelligence
  • Today
  • Operator
  • Work
  • Performance
  • Records
  • Connect
• Growth
  • Overview
  • Be Found
  • Take Demand
  • Bring Customers Back
• Operations
  • Contextual Retail or Restaurant areas
• Settings

The exact visible items are derived from business profile, enabled capabilities and actor permissions.

12.2 Navigation rules #

• No product adds a second permanent sidebar inside the Dashboard.
• Contextual subsections use page-level tabs, local navigation or a compact section index.
• Deep operational routes remain directly addressable.
• Old routes map to one destination: Intelligence, Growth, Operations, Hyper, Settings, external handoff or retirement.
• Ask Resk remains available contextually on authorised Intelligence, Growth and Operations pages and can invoke the same business-wide action registry without replacing the dedicated Operator page.
• Labels describe customer outcomes rather than internal service names.

12.3 Tenant-context requirements #

• Business name must remain stable across summary and detail pages.
• Generic labels such as Retail Store or Default are not substitutes for configured business and location names.
• Every write displays the affected business, location and channel before confirmation.
• Cross-host handoffs preserve context without leaking credentials in URLs.

13. Functional Requirements #

Priority describes delivery sequence, not product scope. P0 establishes the structural and security foundation. P1 completes the full product before general availability. There are no optional requirements in this PRD.

REQ-001: Three-product entitlement model #

Release priority: P0 - foundation

The platform must represent Intelligence, Growth and Operations as the three core product entitlements, with Hyper POS as an optional Operations channel.

Acceptance criteria:

• Product and sales materials use the same three-product model.
• Hyper enablement does not create a duplicate Operations entitlement.
• Online-only customers can activate Operations without Hyper.

REQ-002: Single Dashboard shell #

Release priority: P0 - foundation

The Dashboard must provide one responsive navigation shell for all three products.

Acceptance criteria:

• No nested permanent sidebar appears.
• Current product, section, business and location remain visible.
• Narrow, tablet and desktop layouts preserve access to all authorised content.

REQ-003: Capability-aware navigation #

Release priority: P0 - foundation

Navigation must be generated from business profile, connected systems, product entitlement, channel enablement and actor permission.

Acceptance criteria:

• Online-only tenants see no POS controls.
• Cashiers see no management-only controls.
• Read-only connectors do not produce executable actions.
• Disabled capabilities provide an intentional setup or upgrade path rather than a broken route.

REQ-004: Intelligence façade #

Release priority: P1 - required before general availability

Intelligence must consume stable business-context contracts instead of rebuilding domain joins in the browser.

Acceptance criteria:

• Today, Work, Performance, Records and Connect use versioned contracts.
• Evidence includes source, freshness and capability state.
• Operator actions retain approval, execution and verification receipts.

REQ-005: Unified Growth workspace #

Release priority: P1 - required before general availability

Growth must bring discovery, demand and retention capabilities into one product.

Acceptance criteria:

• Website, SEO, listings, reviews, phone, bookings, campaigns, offers, referrals, loyalty, email and SMS have clear canonical destinations.
• Engagement Studio remains a Growth workspace.
• Provider-specific actions degrade to honest handoffs where API access is unavailable.

REQ-006: Canonical Operations workspace #

Release priority: P0 - foundation

Operations must expose the appropriate Retail or Restaurant management workflows in Dashboard.

Acceptance criteria:

• Retail contains the eight required operational areas and online fulfilment.
• Restaurant contains its domain-specific menu, ingredient, service and kitchen workflows.
• Shared-looking UI does not merge vertical calculation ownership.

REQ-007: Focused Hyper till #

Release priority: P0 - foundation

Hyper must contain only till-adjacent workflows and permission-gated, state-preserving manager handoffs.

Acceptance criteria:

• Back Office is replaced with Open Dashboard.
• Full reports and management settings are not embedded in Hyper.
• Active register state survives the handoff.

REQ-008: Controlled route migration #

Release priority: P0 - foundation

Existing Dashboard, Retail and POS routes must be inventoried and assigned a destination before removal.

Acceptance criteria:

• Every known route has a documented disposition.
• Redirects preserve relative destination and authorised context.
• Redirect loops and cross-host login loops have automated coverage.
• Compatibility telemetry shows remaining old-route usage.

REQ-009: Shared order-channel model #

Release priority: P1 - required before general availability

Online, POS, phone, marketplace, kiosk and QR demand must resolve to canonical vertical orders with an explicit channel.

Acceptance criteria:

• Reports segment and combine channels without duplication.
• Payments record the payment surface separately from the order origin.
• Omnichannel customers share catalogue, inventory and customer truth.

REQ-010: Procurement proof journey #

Release priority: P1 - required before general availability

Retail and Restaurant procurement must support an evidence-backed low-stock to receiving journey.

Acceptance criteria:

• Supplier-less products are named and require human resolution.
• A draft purchase order preserves source evidence and approval.
• Receiving updates the canonical ledger and reads the result back.
• Cost and margin effects are visible without claiming unsupported savings.

REQ-011: Role and permission clarity #

Release priority: P0 - foundation

Back-office users, POS cashiers and system roles must be understandable and least-privileged.

Acceptance criteria:

• The UI explains the difference between business users and cashier profiles where separate.
• Permissions cover product, location and action scope.
• Sensitive actions require manager or owner permission and are audited.

REQ-012: Durable audit and observability #

Release priority: P0 - foundation

Cross-product actions must produce traceable records.

Acceptance criteria:

• Correlation identifiers link Operator work, domain writes, payments and verification.
• Logs do not expose credentials or unnecessary personal data.
• User-visible receipts survive retries and delayed provider callbacks.

REQ-013: Business-wide Operator action registry and governed execution #

Release priority: P0 - foundation

Operator must expose and govern every supported action across Intelligence, Growth, Retail Operations, Restaurant Operations, payments, team settings and Connect, while executing each action through its canonical owner.

Acceptance criteria:

• An action inventory assigns every in-scope business action one state: executable, approval-required, human handoff, missing backend capability or prohibited.
• Every executable action declares its stable identifier, owning API, entitlement, actor and location permission, risk class, preview, idempotency behaviour, canonical read-back and recovery path.
• Operator can create and administer referral programmes, individual referrals or referral codes and reward lifecycle actions through the canonical referral and loyalty owner when the capability is enabled.
• Contextual Ask Resk and the dedicated Operator page use the same registry and enforcement path.
• R2 and R3 actions cannot execute without the confirmation or approval required by the tenant policy and actor role.
• An action is not labelled verified until the owning service or provider is read back and a durable receipt is stored.
• Direct database writes, hidden screen automation, credential exposure and capability invention are rejected by design and test coverage.

14. Non-Functional Requirements #

14.1 Security and privacy #

• Existing authentication and tenant isolation remain authoritative.
• 100% of write-capable endpoints enforce tenant and actor authorisation server-side, regardless of client visibility.
• Cross-host handoffs use HttpOnly, HTTPS-only and SameSite session cookies or a single-use server exchange; bearer credentials never appear in URLs.
• GDPR rights, retention, communication consent and suppression remain enforceable.
• Approval receipts record actor, business, location, action, evidence and result.
• Automated security tests cover horizontal tenant access and privilege escalation for every P0 write family, with zero passing unauthorised writes as the release target.
• Operator evaluates entitlement, tenant, actor, location, connector and risk policy on the server for 100% of executable actions; conversational intent never expands authority.

14.2 Reliability #

• Hyper till availability does not depend on Dashboard availability within the existing offline support boundary.
• Redirect and handoff tests permit zero loss of active cart lines, cashier identity, counter, drawer state or shift identity.
• Provider timeouts preserve monotonic payment and order state.
• Retriable writes use an idempotency key and create at most one canonical record per logical action.
• Automated route coverage permits zero redirect loops across the inventoried compatibility matrix.

14.3 Performance #

• On supported Hyper hardware with a warm local catalogue, barcode-to-cart and cart-quantity interactions target p95 below 200 ms, excluding payment-provider latency.
• On the supported broadband test profile, an already-authenticated Dashboard product switch targets p75 below 1 second and p95 below 2 seconds to usable content.
• Dashboard product navigation does not introduce browser-side fan-out to multiple services.
• Large catalogues and stock ledgers use server pagination and explicit loading states.
• Online-only customers do not download POS-only modules during normal Dashboard use where bundle boundaries permit separation.
• The performance test report records device, browser, network profile, catalogue size and sample count so the figures can be reproduced.

14.4 Accessibility #

• WCAG 2.2 AA is the release target for Dashboard and Hyper.
• Keyboard navigation, focus visibility, accessible names and landmark structure are verified.
• Content remains visible by default and is not gated by entrance animation.
• Text contrast, touch target size and zoom behaviour are tested at supported viewports.
• Critical owner, manager and cashier journeys pass at 200% browser zoom without clipped text or unreachable controls.
• Automated accessibility checks report zero critical or serious violations on the route acceptance set, followed by manual keyboard and screen-reader review.

14.5 Design quality #

• One coherent Resk visual language spans Dashboard products.
• Hyper retains its deliberate dark till environment where operationally appropriate.
• Navigation and hierarchy solve the product problem before decorative styling.
• Empty states describe the real task and never reuse unrelated catalogue copy.
• Loading states do not flash incorrect zero values as settled business truth.
• Status styling is reserved for actual status rather than wrapping every metadata value in a chip.
• Dashboard has exactly one permanent sidebar. Product areas use the same shell and page-level navigation rather than a second rail.
• Operational work uses tables, ledgers, filters and detail views where users compare records; it does not convert every capability into a decorative card grid.
• Icons and real provider marks are used only when they clarify recognition or action. They are not placed in decorative colour tiles.
• The shipped interface contains no decorative blue-purple gradients, glowy buttons, floating cards, generic entrance reveals, hover-lift buttons or inactive controls.
• Buttons, tabs, filters, accordions, drawers and handoffs are pointer-tested and keyboard-tested in the browser before release.
• Parallel columns and repeated rows align to a shared grid; ordinary content has consistent gutters and no text or control is clipped by fixed heights, notches or overflow rules.
• Content and controls remain visible if animation is disabled, JavaScript animation is throttled or reduced motion is requested.
• Design review uses real tenant-shaped content at narrow, tablet and desktop widths and records every discrepancy before the phase gate is signed.

14.6 Compatibility #

• Current Chrome, Edge, Safari and Firefox Dashboard support is verified.
• Hyper is verified in browser, installed desktop and supported tablet/PWA environments separately.
• Existing customer display, printer, scanner, terminal and drawer integrations remain within their current supported environments.
• The release matrix covers the latest two stable major versions of Chrome, Edge, Safari and Firefox available at the start of the validation phase.

15. Technical Architecture Boundaries #

15.1 Existing domain ownership #

• Retail services retain retail catalogue, order, inventory, purchasing and fulfilment rules.
• Restaurant Service retains restaurant orders, tables, menu, delivery, catering, inventory and supplier rules.
• Voice Integrations retains customer identity projections, communications, engagement, referral and loyalty capabilities where already owned.
• Payment services retain canonical payment, invoice, refund and reconciliation state.
• Intelligence receives bounded, versioned business-context contracts.
• Connect exposes external system capabilities, permissions and freshness.
• Intelligence owns the Operator action registry and governance lifecycle; each domain owns its action adapter, validation, write and canonical read-back.

15.2 Frontend composition #

• Dashboard renders Intelligence, Growth and Operations inside one shell.
• Hyper renders a dedicated till shell.
• Shared design primitives do not require shared workflow ownership.
• Operational pages may be reused across compatible hosts during migration, but the final canonical management host is Dashboard.

15.3 Data contracts #

Minimum shared concepts:

• BusinessContext
• LocationContext
• ActorCapability
• ConnectorCapability
• WorkItem and WorkReceipt
• OperatorActionDefinition, OperatorActionRequest and OperatorActionReceipt
• OrderChannel and PaymentSurface
• CustomerReference and CommunicationPermission
• Product or Menu Reference
• InventoryMovement Reference
• Approval and Verification Receipt

These contracts reference canonical domain identifiers rather than copying full domain records into a new Resk-wide database.

The Operator registry is a capability catalogue, not a replacement workflow engine or system of record. An action definition points to an owning API adapter and cannot contain domain calculations that belong to Retail, Restaurant, Growth, Payments, Auth or a provider.

15.4 No-new-service rule #

The product reorganisation must not introduce a new service merely because there are three product navigation areas. New backend work is permitted only where a bounded contract, missing domain capability, security control or durable orchestration requirement justifies it.

15.5 API grouping and versioning #

Status: target architecture, not a completed migration. Group the dashboard-facing contracts by the three products without moving domain calculations or creating three new backend services. The exact public aliases require contract review before rollout.

Shared authentication, business/location context, permissions, subscriptions and integrations remain platform capabilities, not a fourth product. The existing /voice/product-profile/v1 contract supplies product/profile context; its presence does not prove every frontend route consumes it. Provider callbacks, webhooks, internal service routes and public/guest APIs keep explicit, separately governed boundaries rather than being blindly renamed.

Contract requirements:

• One owned OpenAPI contract per product family, with typed success and error responses, examples and stable operation identifiers. Request-only DTO generation is insufficient.
• A generated or contract-checked TypeScript client and fixtures for Restaurant, Retail, online-only, supported hybrid, restricted and disabled profiles.
• Business and location scope resolved and validated by trusted server code. Clients cannot choose their own authority by changing a header or URL.
• Explicit error codes, retryability, pagination, currency, timezone, source provenance, actual freshness and unavailable/null semantics. A missing value is not zero.
• Consistent idempotency and optimistic concurrency on applicable writes, with documented conflict behavior and canonical action/read-back receipts.
• Product versions evolve independently. Additive compatible changes stay within a supported major version; removals or changed meanings require a new major contract and a migration period.
• Compatibility adapters preserve old clients, bookmarks, auth, guest flows, Hyper and provider callbacks. Do not switch or remove an endpoint until old/new response and side-effect parity is demonstrated.
• CI validates response examples, generated-client drift, approved endpoint inventory, forbidden browser aggregation and backward compatibility. Publish the contract artifact with its revision, owning team, changelog and migration guidance.

Delivery order: inventory and ownership first; complete and freeze a usable response contract; add tested compatibility aliases where agreed; migrate one product journey at a time; verify old/new clients, authorization and canonical writes; deprecate only after usage evidence and rollback review. Grouped API documentation and URL names alone do not complete this work.

Exit evidence: a frontend developer can implement each approved screen from the published product contract without discovering hidden service joins, inventing missing fields or bypassing the owning domain's permissions and calculations.

16. Success Metrics #

Product-structure metrics #

• Every current route has one documented canonical destination.
• Zero Dashboard pages show two permanent product sidebars.
• Zero online-only tenants see POS-specific navigation after profile activation.
• Every Hyper back-office path either remains a till route or redirects safely to its Dashboard equivalent.
• Every in-scope Operator action has one registry state and one canonical owner; zero actions remain unclassified at the Phase 5 gate.

Adoption metrics #

• Owners can reach Today, Growth and Operations from the global navigation without entering Hyper.
• Cashiers can complete their core shift without entering Dashboard.
• Online-only retailers can complete catalogue to order to fulfilment to report without a POS entitlement.
• Omnichannel businesses can trace one product and one customer across online and in-store orders.
• An authorised owner can ask Operator to create a referral, complete the required approval, and see the canonical referral and reward status without navigating to a separate legacy product area.

Trust metrics #

• Every Operator write produces a read-back result or visible exception.
• 100% of executed Operator pilot actions resolve to a durable verified receipt or explicit exception; request acceptance alone counts as neither.
• Every displayed connector action states whether it is read-only, recommend-only, approval-required or executable.
• Financial outcome claims reconcile to canonical order and provider state.
• Procurement pilots produce durable evidence from low-stock signal through receiving.

Experience metrics #

• No old-route redirect loop in automated and pilot testing.
• No active Hyper cart, cashier or shift is lost when opening Dashboard.
• Critical workflows pass keyboard and screen-reader checks.
• Empty-state and delayed-load screens never present temporary zero values as final truth.

No deadline or percentage rollout is fixed in this PRD. Each phase advances only after its exit evidence is satisfied.

17. Delivery Roadmap #

Phase 0: Architecture and route inventory #

Outcomes:

• Confirm three-product terminology across Product, Design, Engineering, Sales and Support.
• Inventory Dashboard, Growth, Retail, Restaurant and Hyper routes.
• Assign each route to Intelligence, Growth, Operations, Hyper, Settings, external handoff, redirect or retirement.
• Confirm canonical domain and API owner for every write-capable workflow.

Exit evidence:

• Signed route disposition matrix.
• Signed ownership and capability matrix.
• No unresolved route with live customer traffic.

Phase 1: Single Dashboard shell #

Outcomes:

• Introduce the one-sidebar Dashboard information architecture.
• Establish product entitlements, business profiles and actor capability navigation.
• Preserve direct deep links and compatibility paths.

Exit evidence:

• Desktop, tablet and narrow viewport review.
• No nested product sidebar.
• Online-only profile demonstrates zero POS navigation.

Phase 2: Operations canonicalisation #

Outcomes:

• Make Dashboard the canonical Retail and Restaurant management surface.
• Separate Stock Activity from manual Stock Adjustments.
• Clarify users versus cashiers and meaningful location names.
• Deliver catalogue workbook and multi-line receiving improvements where the existing workflow is insufficient.

Exit evidence:

• Inside Africa operational read paths match current production data.
• No duplicated record created through host migration.
• Supplier, PO, stock count and transfer journeys pass with authorised test data.

Phase 3: Hyper separation #

Outcomes:

• Replace Back Office with Open Dashboard.
• Restrict the handoff by permission.
• Redirect non-till POS-host routes to Dashboard.
• Preserve browser, PWA and desktop register continuity.

Exit evidence:

• Active cart and shift survive the handoff.
• Cashier cannot enter management routes.
• Offline Hyper shows an explicit Dashboard-unavailable state without leaving or resetting the till.
• Existing bookmarks reach the equivalent management destination.

Phase 4: Growth consolidation #

Outcomes:

• Group website, SEO, reviews, phone, booking, campaigns, offers, referrals, loyalty, email and SMS under Growth.
• Retain Engagement Studio as the campaign workspace.
• Add capability-aware provider states and verified handoffs.

Exit evidence:

• No Growth capability remains discoverable only through a legacy product area.
• Cross-vertical referral, loyalty and offer entitlements are verified.
• Growth-originated demand resolves to canonical Operations records.

Phase 5: Intelligence completion #

Outcomes:

• Stabilise versioned Intelligence contracts.
• Complete the dedicated Operator page and contextual Ask Resk entry.
• Deliver the versioned Operator action registry, risk classes and server-side enforcement.
• Connect action cards to canonical Growth, Retail, Restaurant, payment, team-setting and connector workflows.
• Make referral creation and reward lifecycle management a proven first-class Operator action.

Exit evidence:

• The complete in-scope action inventory has an executable, approval-required, human-handoff, missing-capability or prohibited state with no unclassified item.
• One real Growth referral journey, one Retail operations journey and one Restaurant journey move from evidence through approval to execution or handoff and verified outcome.
• One R0, R1, R2 and R3 action passes its expected permission, approval, idempotency and read-back path; an R4 action is visibly rejected.
• Records preserve the durable receipt and failure path.

Phase 6: Tenant pilots and controlled rollout #

Pilot profiles:

• Inside Africa as a physical or omnichannel retail tenant using Hyper.
• The two existing online-only retail tenants after their exact identifiers and owners are confirmed.
• One Restaurant tenant with current menu, order and service workflows.
• A negative-control tenant for disabled capabilities.

Exit evidence:

• Product, runtime, tenant configuration and observed UI evidence agree.
• Support runbooks and rollback paths are approved.
• No customer-wide activation occurs solely because source code or deployment is green.

18. Validation Checkpoints #

Each checkpoint is a stop/go gate. Evidence is attached to the delivery record; a code merge or healthy deployment is insufficient by itself.

19. Validation Scenarios #

Scenario A: Online-only retailer #

1. Owner signs into Dashboard.
2. Navigation shows Intelligence, Growth and Retail Operations.
3. No Register, Drawer, Shift, Hardware or Customer Display control is visible.
4. Owner updates a product, receives an online order, fulfils it and views the result in Reports.
5. Intelligence reflects the canonical order and outcome.

Scenario B: Inside Africa owner and cashier #

1. Cashier uses Hyper for register work.
2. Cashier without management permission does not see Open Dashboard.
3. Owner or manager opens Dashboard in a separate context.
4. Active Hyper cart and shift remain unchanged.
5. Owner reviews catalogue, inventory, suppliers and reports in Dashboard.
6. A low-stock item with no supplier creates a visible human-resolution requirement rather than a guessed PO.

Scenario C: Omnichannel retail #

1. One product sells online and in Hyper.
2. Both orders reduce the same canonical inventory ledger.
3. Reports distinguish order channel and payment surface.
4. Customer history shows both transactions without duplicate identities.

Scenario D: Software-first restaurant #

1. Restaurant launches website, phone AI, bookings and online ordering without Resk POS hardware.
2. Existing external POS capability is shown accurately in Connect.
3. Growth-originated booking or order reaches Restaurant Operations.
4. Operator can propose work but cannot exceed connector capability.

Scenario E: Verified Operator action #

1. Intelligence detects a measurable risk or opportunity.
2. Operator displays evidence and prepares an action.
3. Owner edits or approves it.
4. The owning domain executes it.
5. Intelligence reads the result back.
6. Records preserve the complete receipt or exception.

Scenario F: Operator creates and verifies a referral #

1. An authorised owner asks Operator to create a referral for an eligible Growth tenant.
2. Operator resolves the canonical referral capability, advocate, referred customer where supplied, reward rules, consent requirements and actor permission.
3. Operator shows the final referral or programme preview and requests the approval required by its risk class.
4. The canonical referral and loyalty owner creates the programme, referral, link or code and any associated reward state.
5. Operator reads back the referral identifier, status, customer timeline and reward ledger state.
6. Records stores the request, approval, execution correlation, read-back and receipt.
7. A retry with the same idempotency key creates no duplicate referral or reward.

Scenario G: Operator is refused authority it does not have #

1. A cashier asks Operator to change tax, issue an unapproved refund or alter a role.
2. The server evaluates tenant, actor, location and R3 policy.
3. Execution is rejected before the owning write API is called.
4. Operator explains the required authorised role or approval without exposing hidden data.
5. Records stores the refusal without creating the requested business change.

20. Out of Scope #

This PRD does not include:

• A rewrite of Retail Service or Restaurant Service.
• A new monolithic Resk Operations backend.
• Automatic migration of every customer without tenant-specific validation.
• Removal of compatibility routes before observed usage reaches the approved retirement threshold.
• Replacement of Hyper's register design or payment engine unless required for the management handoff.
• Automatic supplier guessing or autonomous purchasing without evidence and approval.
• Provider integrations that lack approved credentials, contracts or supported APIs.
• Claims that Google, Yelp or Trustpilot actions are executable before provider access is verified.
• A production dependency on the referenced open-source SEO repositories.
• An unrestricted Operator superuser, direct database mutation or automation that clicks hidden UI controls instead of using an owned capability contract.
• Operator execution of a provider action that the connected account, provider API, tenant consent or Resk adapter does not support.
• A merge to development or production.
• Hardware rollout, POS installation or customer activation.

21. Risks and Mitigations #

22. Decision Log #

23. Final Positioning #

Resk Intelligence #

See what is happening. Ask Resk to act across the business. Approve the work. Verify the result.

Resk Growth #

Be found. Take demand. Bring customers back.

Resk Operations #

Run the work behind every sale.

Hyper POS #

Run every in-person sale.

One-sentence company story #

Resk is the AI operating system that helps businesses grow demand, run operations and protect revenue, with an optional Hyper till for in-person selling.

Operator is the operating layer across all three products: if an action is supported, permitted and connected, the business can ask Resk to do it and verify the result.

24. Task Breakdown Hints #

The implementation task graph should be organised into these delivery lanes:

1. Product terminology, route inventory and canonical ownership
2. Entitlements, tenant profiles and actor capabilities
3. Single Dashboard shell and navigation migration
4. Retail Operations canonicalisation
5. Restaurant Operations canonicalisation
6. Hyper Dashboard handoff and route redirects
7. Growth consolidation and provider-capability states
8. Intelligence façade and business-wide Operator action registry
9. Operator domain adapters, risk policy, approvals, idempotency and receipts
10. Cross-channel order, payment and reporting semantics
11. RBAC, cashier identity and location context
12. Browser, PWA, desktop, accessibility and offline verification
13. Real-tenant pilots, including referral creation, controlled rollout and rollback

Every delivery task must identify the owning repository or service, prohibited scope, dependencies, verification evidence and customer-visible acceptance criteria before implementation begins.

25. Current Brief for Abdulbasit Bankole #

25.1 Design scope and engineering boundary #

Design the whole Dashboard experience across Intelligence, Growth and Operations, not a new overview that sends users back into unrelated legacy navigation. Preserve working capabilities and their domain ownership. The redesign is not required to preserve the current layout, styling, repeated headers or nesting.

Use one permanent Dashboard sidebar. Product and section selection must be apparent, but no product adds a second full-height navigation rail. Deep workflows remain within the current product shell; a cross-product handoff is reserved for a genuine ownership change and preserves the exact business, location, record and return context.

Abdulbasit owns the design handoff described here. Stephen and Dayo's existing tickets support it. This PRD does not claim that Abdulbasit has approved the current interface, delivered final designs or accepted any engineering ticket.

25.2 Required design inventory #

A real workflow includes creation or edit where supported, validation, unsaved changes, pending protection, permission denial, success with evidence, failure and retry or recovery. A navigation item or decorative summary card does not count as that workflow.

25.3 Business-shaped variants #

• Restaurant: service horizon, bookings/covers, ingredients, menu availability, prep, food/labor cost, waste, suppliers and service execution. No unexplained retail SKU or till assumptions.
• Online-only Retail: catalogue, stock, orders, fulfillment, purchasing, returns and reports with no register, drawer, shifts, customer display or POS hardware prerequisite.
• Physical/omnichannel Retail: the same canonical management records plus optional Hyper and channel-aware reporting. A showroom, beauty store, expiry-aware grocer and ecommerce business may need different capability-driven detail.
• Supported hybrid: business and location context must resolve explicitly; do not silently default to Restaurant or show a decorative vertical toggle that leaves authority and data unchanged.
• External-POS business: read, write and verification limits must be visible. An external POS is not a second-class profile and does not require installing Hyper.
• Restricted and disabled profiles: designs must include forbidden, unavailable, not configured, read-only and approval-required states. Hiding a control is not backend authorization.

25.4 Contract-linked handover format #

For every screen, provide its purpose, canonical product/route, business profiles, data fields, owning endpoint/version, loading/empty/stale/partial/error/forbidden states, controls, mutation consequences, approval/receipt behavior and return destination. Mark each backend field or action as available, contract gap, integration pending or unsupported/handoff using the current delivery evidence.

Deliver:

1. A capability and route map for all three products, including legacy dispositions and genuine cross-product handoffs.
2. One coherent component and content system: tables, forms, detail views, dialogs, state language, keyboard/focus behavior and responsive rules.
3. Desktop, tablet and narrow-screen designs for the inventory above, plus 200% zoom and long-content examples.
4. Clickable end-to-end journeys tied to real contract states, not only populated happy-path screens.
5. A field/action gap register for Stephen and Dayo, with the owning existing ticket and acceptance evidence needed. A designer should not silently invent an API.
6. A joint design/engineering acceptance record before implementation is called final.

The previous 224-route count was an August 24 migration snapshot, not 224 screens to draw. Later inventories use different dates and scopes. Refresh the current complete route inventory and record a disposition for each route before retirement; do not carry an old count forward as a completeness claim.

25.5 Pilot journeys to prototype and then prove #

Saved views, role-aware briefs, assignment evidence, proactive brief delivery, outcome history, portfolio views and scenario planning from the original Intelligence brief remain tracked design requirements or explicitly sequenced extensions. They are not declared delivered by the new shell. Scenario estimates must never be presented as settled business results.

25.6 Definition of ready and done #

Ready for design: product ownership and journeys are clear. This PRD provides that baseline now; incomplete APIs do not prevent exploration of the correct experience.

Ready for implementation: each selected journey has an approved design, actual response schema and fixture, permitted mutation contract, defined failure/partial states and named unresolved gaps. Today this is not true for every screen.

Done: the implemented journey matches the approved design in the browser, uses the intended contract, passes permission and negative cases, preserves navigation/context, and produces canonical read-back or an explicit exception for writes. Product, design and engineering sign-off is separate from Jira state, merge status and deployment success.

26. Revision and Evidence Register #

Revision history #

Audited code revisions #

Key source anchors:

• Intelligence response types, Today/context implementation and Connect implementation.
• Frontdesk Today, send path and generated types.
• Current frontend Operator calls, Frontdesk consumers, Agent data aggregation and API inventory check.
• Operator/Operations repair and QA handover. Its pre-release statements are dated local snapshots; use PR 830 and its deployment record for the subsequent dev release.

The four original Jira descriptions, current statuses and linked PRs were read for this revision. The three adjacent Growth Report/catalogue tickets were checked only for status and merged-code presence. No live provider send, payment, stock, supplier, purchasing, refund, role or tenant-setting mutation was performed during this audit. Claims of full product acceptance require the remaining evidence in sections 0, 18, 19 and 25.

End of PRD