E R A Y

Case study · Active development

SupportFlow AI

A production-oriented, multi-tenant support platform with implemented ticket, audit, and document-ingestion workflows. The AI-assisted retrieval layer is still in development.

← Back to Projects
SupportFlow AI project cover showing the support workflow concept
Concept cover · not a live product screenshot

SupportFlow project summary

  • Active developmentWeeks 1–4 implemented; AWS staging work is in progress
  • Collaborative projectCo-developed by Emir and Eray with rotating feature ownership
  • Backend & dataPython 3.13, FastAPI, PostgreSQL, Redis, and Celery
  • Evidence-ledClaims were checked against the private codebase, tests, CI, and ADRs

Project overview

The problem

Documentation-heavy support teams spend time searching product knowledge and previous resolutions. Ungrounded assistants create a second problem: an answer can sound convincing without being traceable.

SupportFlow targets small and medium-sized Turkish B2B SaaS teams. The implemented system establishes the secure support and ingestion foundation before AI-generated drafts are introduced.

Implemented workflow

What works today

  • Authenticated agents work with tenant-scoped tickets, messages, and status transitions.
  • Admins upload PDF, TXT, or Markdown documents through a bounded private-storage workflow.
  • Redis and Celery process extraction jobs with retry and redelivery safeguards.
  • Ticket, membership, document, and workflow changes produce append-only audit evidence.

Truthful delivery status

Implemented, in progress, and planned

Implemented

  • Argon2id authentication, short-lived tokens, and admin/agent RBAC.
  • Verified organization context and tenant-scoped ticket/message APIs.
  • Transactional mutations with database-enforced append-only audit events.
  • Agent workspace with server-side sessions and CSRF protection.
  • 10 MiB bounded document uploads, extraction, and retry-safe Celery processing.
  • PostgreSQL, Alembic, Docker Compose, tests, and CI checks.

In progress

  • AWS staging platform and cost/safety guardrails.
  • S3 storage, production scanner, shared session, and readiness adapters.
  • GitHub OIDC and immutable-image deployment pipeline.
  • Staging verification, rollback, recovery, and teardown evidence.

Planned

  • Structured ticket classification with evaluation fixtures.
  • Tenant-filtered retrieval, citations, and no-answer thresholds.
  • Human approve, edit, reject, and feedback workflow for AI drafts.
  • Retrieval evaluation, load evidence, observability, and product validation.

Modular monolith

Architecture with explicit boundaries

supportflow / current and target flow

ImplementedPlanned

Implemented application path

  1. ImplementedAgent workspaceSigned server-side session and CSRF-protected actions
  2. ImplementedFastAPI boundaryValidation, RBAC, and verified organization context
  3. ImplementedPostgreSQLTenant-scoped data, Alembic migrations, append-only audit
  4. ImplementedPrivate documentsBounded uploads and local S3-ready storage abstraction

Implemented asynchronous ingestion path

  1. ImplementedID-only jobNo raw document content in Celery task arguments
  2. ImplementedRedis queueBroker boundary for background processing
  3. ImplementedCelery workerLate ACK, worker-loss rejection, bounded retry
  4. ImplementedExtraction resultRetry-safe terminal state and one audit effect

Planned AI-assisted support path

  1. PlannedClassificationProvider-neutral structured output and evaluation
  2. PlannedGrounded retrievalTenant filters, citations, and insufficient-context result
  3. PlannedAgent decisionApprove, edit, reject, and feedback—never auto-send

Engineering decisions

Choices, reasons, and trade-offs

Tenant isolation

Problem
A valid user must not cross organization boundaries.
Decision
Reload membership and role context from PostgreSQL, then scope every repository query.
Reason
Authorization depends on current database truth—not only token claims.
Trade-off
Every request carries explicit organization context and a database authorization check.

Auditable mutations

Problem
Business changes and their audit trail must not diverge.
Decision
Write the domain mutation and allowlisted audit event in one transaction; block audit UPDATE, DELETE, and TRUNCATE with PostgreSQL triggers.
Reason
Rollback keeps the change and its evidence consistent.
Trade-off
The trigger does not protect against a privileged database owner.

Retry-safe workers

Problem
A worker may crash after claiming a document job.
Decision
Send only the version ID, acknowledge late, reject on worker loss, claim the row, and make terminal effects idempotent.
Reason
Redis redelivery can converge without duplicated output or audit events.
Trade-off
A small database-commit-to-queue-publish window remains until an outbox or reconciler is added.

Bounded upload boundary

Problem
Document input is untrusted and can exhaust memory or bypass type checks.
Decision
Stream to a bounded temporary file, normalize names, verify extension/content, and cap files at 10 MiB.
Reason
Validation happens before persistence and background processing.
Trade-off
The current scanner is local/test only; production scanning and live S3 are still in progress.

Implemented controls

Reliability & security

  • Same 404 boundary for missing and cross-tenant resources reduces tenant-discovery signals.
  • Atomic ticket workflows keep status, message, and audit mutations in one transaction.
  • Opaque browser sessions rotate on login and invalidate on logout; cookies are HttpOnly and SameSite=Lax.
  • Safe task payloads carry a UUID rather than file contents, extracted text, or storage paths.
  • Worker redelivery coverage includes forced process loss and duplicate-delivery behavior.
  • Synthetic data by default; no real customer ticket or production-user claim is made.

Repository evidence · verified Aug 2026

Testing that proves behavior

187Collected automated test cases across unit and PostgreSQL integration layers
PostgreSQLTenant, migration, transaction, and integration coverage
Worker lossRedis redelivery and duplicate-effect convergence scenario

The local review passed the dependency-lock, Ruff, formatting, Pyright, and 105 environment-independent tests. The remaining 82 PostgreSQL tests were collected but not rerun locally because Docker was unavailable; the private CI workflow defines database, migration, container, ingestion, and worker-loss runs. These are engineering checks—not uptime, scale, or production-SLA claims.

Ownership

My contribution

  • Led the initial PostgreSQL, Redis, Docker Compose, testing, and CI foundation.
  • Led ticket/message workflow and agent-workspace integration, including the audit transaction boundary.
  • Contributed across shared authentication, document ingestion, worker reliability, review, and integration work.
  • In progress: AWS account safety, Terraform platform, GitHub OIDC pipeline, and Week 5 release operations.

SupportFlow AI is co-developed by Emir and Eray. Feature ownership rotates and merged code is reviewed as shared system knowledge. Emir led identity/membership and audit-schema streams, plus the document-upload contract; this page separates my contribution from the team’s total output.

Engineering stack

Tools used today

Python 3.13FastAPIPydanticPostgreSQLSQLAlchemyAlembicRedisCeleryDocker ComposepytestRuffPyrightGitHub Actions

Designed, not deployed: AWS ECS/Fargate, RDS/pgvector, ElastiCache, S3, ECR, Secrets Manager, CloudWatch, Terraform, and GitHub OIDC.

Known limitations

What this project does not claim

  • No live AWS staging or production deployment yet.
  • No implemented AI classification, RAG, citations, or human-approval flow yet.
  • The browser session store is process-local and not suitable for multiple API instances.
  • The local/test scanner is not a production malware-scanning boundary.
  • No real-user validation, concurrent-load evidence, uptime record, or commercial usage.

Next steps

The evidence still to earn

  1. Complete and verify the AWS staging platform, adapters, deployment, rollback, and teardown path.
  2. Close the commit-to-dispatch gap with an outbox, reconciler, or explicitly accepted staging recovery plan.
  3. Implement classification and measure structured-output quality on fixed fixtures.
  4. Implement tenant-filtered retrieval, citations, no-answer behavior, and human approval.
  5. Publish retrieval, latency, cost, load, and agent-decision evidence before making production claims.

Private repository

Source access is disclosed clearly.

The shared team repository is private. This case study summarizes claims verified against the application code, migrations, test suite, ADRs, CI configuration, and contribution history. Public source access and a live demo are not currently available.