Atlas layer / system tracks Choose by operating gap
Atlas / System tracks

Select by failure point

Four tracks. No automatic full rebuild.

An organization in Morocco may need a new interface, a better internal sequence, a connection between existing tools, or a measured replacement of fragile software. Discovery determines which route earns the cost.

Track 01 / Portal

Customer or partner access

Use a portal when people outside the operating team need to submit requests, see status, exchange documents, manage accounts, or complete a defined process. Discovery maps identity, permissions, notifications, language needs, records of truth, support responsibility, and what must remain private behind the interface.

A portal is not automatically a replacement for the systems behind it. A narrow layer can often present the right information while established operational tools remain in place.

Track 02 / Workflow

Internal coordination

Use a workflow system when a request changes hands repeatedly, approvals are unclear, the same information is entered more than once, or managers cannot see where work is blocked. The scope starts with states, roles, exceptions, evidence, and escalation—not a screen list.

The useful measurement may be shorter cycle time, fewer missed handoffs, less duplicate entry, or clearer accountability.

Track 03 / Integration

Connect systems already in use

Use integration when the existing products remain suitable but the transfer between them is manual or unreliable. Each connection needs an owner, authentication plan, data map, retry behavior, monitoring path, and manual fallback. Vendor limitations and API access are confirmed before estimates are treated as commitments.

Track 04 / Modernization

Replace only what has become a liability

Use phased modernization when a critical application cannot be safely maintained, supported, secured, or changed. Inventory current behavior first. Preserve data and essential operations, build acceptance evidence, plan rollback, then move in controlled stages instead of treating a rewrite as a single dramatic launch.

Decision filter

What discovery must answer.

A responsible plan separates an annoying symptom from the operating constraint that causes it.

People

  • Who initiates, approves, fulfils, reviews, and supports?
  • Who owns the final business rule?
  • Which Arabic, French, or English experiences are actually required?

Systems

  • Which product remains the system of record?
  • What data can existing APIs reliably expose?
  • What must happen when a vendor is unavailable?

Acceptance

  • What measurable result justifies the work?
  • Which scenarios must pass before release?
  • Who signs off and who owns maintenance?
Not every discovery should become a custom build. A documented recommendation to configure, simplify, integrate, or keep the current system can be the correct outcome.

Next coordinate

Describe one workflow in plain language.

The project canvas asks for the people, handoffs, current tools, information, and consequence—not a premature technical solution.

Open the project canvas faithforgelabsllc@gmail.com 404-939-0637