← Return to Archive

Clearance Granted | PUBLIC TECHNICAL RECORD

A-02 | Multi Role Product Engineering

AGED Application System

A branch aware operational platform where identity, role, location and workflow all affect what the system allows.

AGED is a multi role operational platform designed around shops, branches, staff and the workflows that connect daily operations.

The system brings attendance, inventory, sales, purchasing, reporting and administrative control into one architecture instead of treating them as isolated screens.

The central engineering problem is scope. A user must not only be authenticated. The system must understand which shop they belong to, which branch they are assigned to and which actions their role is allowed to perform.

Multi Tenant ArchitectureRole Based Access ControlBranch IsolationFlutterOperational WorkflowsAttendanceInventorySales and Finance

Public Case Summary | Direct Answers

What this system is and why it exists.

Status
In Development
Type
Multi Role Product Engineering
Contribution
Product architecture, application development and system design.

What is AGED Application System?

AGED is a multi role operational platform designed around shops, branches, staff and the workflows that connect daily operations.

What problem does AGED Application System address?

Operational software becomes fragile when identity, scope and workflow are treated as separate concerns.

AGED is designed around the idea that every operational action belongs to a user, a role, a tenant and usually a branch. That relationship has to remain consistent from the interface to the backend.

01 | Problem

Operational software becomes fragile when identity, scope and workflow are treated as separate concerns.

AGED is designed around the idea that every operational action belongs to a user, a role, a tenant and usually a branch. That relationship has to remain consistent from the interface to the backend.

Working Principle

Identity alone is not authorization. Role alone is not scope.

01

Multiple shops can exist inside the same platform.

02

Each shop can contain multiple branches.

03

Owners, managers and staff require different visibility.

04

Managers and staff must remain inside their assigned branch scope.

05

Attendance depends on branch location and an active duty session.

06

Closing duty can depend on a role specific operational report.

07

Purchases, inventory and sales must preserve branch context.

08

Owners need consolidated visibility without exposing one tenant to another.

02 | Architecture

One operational system, multiple controlled boundaries.

The application is organized so that authentication establishes identity, the backend resolves scope and feature modules operate only inside that resolved context.

System Route | IDENTITY TO OPERATION

06 Nodes | Public View

  1. FLOW 01

    Client

  2. FLOW 02

    Authentication

  3. FLOW 03

    Server Scope

  4. FLOW 04

    Feature API

  5. FLOW 05

    Branch Data

  6. FLOW 06

    Owner Reporting

Tenant

The shop is the primary organizational boundary for normal users.

Branch

Operational records remain connected to the branch where the work occurs.

Role

Owner, manager and staff responsibilities produce different permissions and workflows.

Duty Session

Attendance state connects location, time, verification and end of shift reporting.

Operations

Inventory, sales and purchases feed branch level operational visibility.

Finance

Owner reporting connects sales and purchase activity for comparison and decision support.

03 | Security

Authorization is a server owned decision.

AGED treats tenant and branch boundaries as backend security rules. Normal users do not become authorized simply because a client sends a shop or branch identifier.

CONTROL 01

Super Admin scope can span the system.

CONTROL 02

Shop Owner or Shop Admin scope is limited to the authenticated shop and its branches.

CONTROL 03

Manager scope is limited to the assigned branch.

CONTROL 04

Staff scope is limited to the assigned branch and allowed role actions.

CONTROL 05

Start Duty requires the assigned branch location and server side geofence validation.

CONTROL 06

End Duty is blocked until the required role specific report exists for the same duty session and branch.

04 | Workflow

Duty completion is an operational workflow, not a single button.

Attendance is connected to location, verification and the employee responsibility that must be completed before the shift can close.

  1. STEP01

    Scheduled Shift

  2. STEP02

    Branch Location Check

  3. STEP03

    Live Verification

  4. STEP04

    Start Duty

  5. STEP05

    Operational Work

  6. STEP06

    Role Specific Report

  7. STEP07

    End Verification

  8. STEP08

    End Duty

05 | Engineering Decisions

The technical choice matters less without the reason behind it.

Decision 01

Server Side Scope Enforcement

Decision

Resolve shop and branch scope from the authenticated profile instead of trusting ordinary client supplied scope.

Why

Client controlled identifiers can be changed and must not become the source of authorization.

Outcome

Tenant and branch boundaries remain part of the backend security model.

Decision 02

Role Specific Closing Reports

Decision

Require different closing evidence depending on the employee role.

Why

A cashier, barista, chef and cleaner do not close a shift with the same operational responsibility.

Outcome

Duty completion becomes connected to the work that actually needs to be reported.

Decision 03

Branch Aware Records

Decision

Keep operational records associated with the originating branch.

Why

Inventory, sales, attendance, purchasing and finance lose meaning when branch context is detached.

Outcome

Owners can inspect branch specific data and consolidated shop level views without flattening the source context.

Decision 04

Location Bound Attendance

Decision

Use the assigned branch location as part of Start Duty validation.

Why

Attendance should represent presence at the operational location rather than only a successful client action.

Outcome

Duty state is tied to branch scope and physical attendance rules.

Decision 05

Workflow Before Convenience

Decision

Block End Duty when required operational reporting is incomplete.

Why

A convenient exit action should not bypass the reporting dependency that the business needs.

Outcome

The system preserves the operational sequence instead of leaving completion to memory.

06 | Evidence

Inspect what can be disclosed.

Evidence 01TECHNICAL

Attendance API Surface

Backend Contract

Record Summary

The attendance lifecycle is represented through dedicated backend routes rather than UI only state.

  • POST /attendance/start-duty
  • POST /attendance/end-duty
  • GET /attendance/current
  • GET /attendance/history
Evidence 02SANITIZED

Tenant and Branch Permission Model

Authorization Model

Record Summary

The public case file exposes the scope model without publishing sensitive implementation detail.

  • Super Admin: system wide
  • Shop Owner: own shop and branches
  • Manager: assigned branch
  • Staff: assigned branch and role permissions
Evidence 03PUBLIC

Duty Workflow

Operational Flow

Record Summary

The duty lifecycle demonstrates how location, verification and reporting dependencies connect.

  • Branch geofence
  • Live photo verification
  • Role report dependency
  • Duty completion
Evidence 04PUBLIC

Release Builds

Build Evidence

Record Summary

The project has produced web and Android release build outputs during development.

  • Flutter web build
  • Android release APK
  • Responsive web interface
  • Mobile application flow
Evidence 05TECHNICAL

Purchase to Finance Relationship

Data Relationship

Record Summary

Purchase activity is designed to feed financial visibility instead of becoming an isolated module.

  • Branch purchase context
  • Owner notification
  • Purchase totals
  • Sales and cost comparison
Evidence 06PLANNED

Future Integration Layer

Roadmap

Record Summary

External operational integrations are being treated as system extensions rather than core authorization boundaries.

  • Foodics
  • Online ordering
  • Loyalty
  • POS
  • Delivery tracking

Technology | Purpose

Application

Flutter

Cross platform mobile and web product interface.

Language

Dart

Application implementation across the Flutter codebase.

State

Riverpod

Application state and dependency organization.

Cloud

AWS

Hosting, APIs and cloud infrastructure used by the production direction.

Web Delivery

AWS Amplify

Deployment and hosting for the web build.

Location

AWS Location Service

Location aware features and map related operational flows.

Security

Server Side Authorization

Tenant, branch and role scope enforcement.

07 | Current State

The case file ends where the next iteration begins.

Product

Active development

Web Build

Completed

Android Release

Built

Multi Branch

Core architecture present

Authorization

Server scoped model

iOS

Not yet built

Production

Preparing

Languages

English, Arabic and Bangla

Case File End

A-02 | AGED Application System

← H-01ArchiveL-03 →