Confidential · Phase 1 Deliverable · For MK Fraud Insights
Phase 1 Solution Design Pack

MK Fraud Readiness Score

The formal Phase 1 design output: a deterministic, transparent, MK-editable scoring engine, the recommended architecture, the data model, the security and cost approach, the implementation roadmap, and a working scoring proof of concept.

Prepared for
MK Fraud Insights
Prepared by
Aveosoft
Phase 1 fee
USD 1,475 fixed
Date · Version
19 June 2026 · v1.0
How the scoring engine stays transparent, reproducible, and editable by MK

The score is a pure deterministic function of your methodology, held as data you own and control.

The MK Fraud Readiness Score is produced by a rule engine that treats your methodology as configuration, not code. The calculation is a pure deterministic function, score(config, answers): the same applicable answers under the same configuration version always produce the same overall score, category scores, maturity band, exposure profile, and recommendations. There is no randomness, no time dependence, no model inference, and no network call inside the calculation. Generative AI never determines, alters, or overrides the score. Every result carries a full per-domain and per-answer trace showing each weight, each critical-control check, and any maturity cap that fired. Questions, weights, maturity bands, critical-control rules, exposure variables, and recommendation text all live as versioned, MK-editable data, so your team changes the methodology without a developer and without a release. A scoring test pack proves expected equals actual before anything goes live. The methodology is yours; Aveosoft builds the system that executes it faithfully. This commitment is the first thing this pack states because it is the heart of the product.

This pack evidences every Phase 1 deliverable in Section 10 of the brief
1 Requirements validation 2 Assumptions, risks, decisions 3 Customer journey 4 Assessment + report workflow 5 Two implementation options 6 Recommended architecture 7 Architecture diagram 8 Data-flow diagram 9 Database structure 10 Report-generation method 11 Security + access 12 Third-party assessment 13 Recurring cost 14 Vendor lock-in 15 Implementation roadmap 16 Fixed-price build proposal 17 Clickable prototype 18 Scoring demonstration
01 Requirements validation · Deliverable #1

What we have validated against the brief

We have reviewed the brief line by line and validated the product MK is building: an established document-based Fraud Readiness Diagnostic across ten capability domains, delivered as a scalable digital product that organisations complete online to obtain a structured, credible view of their fraud readiness and a 30, 60, and 90-day plan to act on it. Three output levels are designed for from the start: an Instant Snapshot, a Full Self-Assessment Report, and an MK-Validated Report, with the validated level supported by a manual MK workflow at launch.

Deterministic, transparent, MK-editable scoring is the central requirement. The same applicable answers must always produce the same result, and MK must trace and edit it without a developer.
Fraud Readiness and Fraud Exposure are two separate dimensions, never merged into one unexplained number.
A failed critical control caps the maturity band regardless of a high average, so a weakness cannot be hidden behind a healthy mean.
MK owns and can export all data, all accounts sit under MK-controlled credentials, and another competent developer can maintain the system.
Non-technical MK staff self-administer questions, weights, report content, and communications without code changes.
A board-grade, MK-branded experience suited to risk committees and boards, not a generic online quiz.
Methodology ownership boundary. MK owns and provides the fraud methodology: questions, response options, weights, maturity rules, critical-control rules, exposure variables, interpretations, and recommendation content. Aveosoft translates that methodology into a reliable, configurable, transparent technical system. We do not invent fraud content, interpret maturity, or decide which risks to prioritise. The sample methodology used in this pack and in the proof of concept is illustrative only; the real methodology is yours.
02 Assumptions, risks, and open decisions · Deliverable #2

The risks we manage, and the decisions we need at kickoff

This engagement hands Aveosoft a clear engineering and configuration boundary, which removes the single largest risk on assessment products: a vendor inventing or quietly distorting the scoring model. The residual risk picture concentrates in five places, each with our recommended handling already attached.

R1 · Methodology still under development.

Some materials may be refined during the design phase, making scope and scoring a moving target. Mitigation: hold the methodology as versioned, externalised configuration so changes never need code edits; lock a baseline version for the proof of concept; written change control re-tests and re-versions any post-acceptance change.

R2 · Scoring correctness and transparency.

A silent calculation error or an untraceable score would destroy the credibility that is the product's entire value. Mitigation: an expected-versus-actual reconciliation harness from an MK-approved test pack, a per-answer trace, fully deterministic calculation, and a hard launch gate. No production launch until scoring reconciles against the approved test cases.

R3 · Critical-control gating misconfigured.

If a failed control does not cap maturity, a weakness hides behind a healthy average. Mitigation: model flags and caps as explicit configurable rules, verified by dedicated test-pack scenarios where each failure must demonstrably cap maturity.

R4 · Data protection, ownership, no public-AI training.

A lapse is both a POPIA exposure and a trust failure. Mitigation: the POPIA-aligned approach in Section 09, MK ownership and export of all data, all accounts under MK credentials, and an absolute rule that no client or methodology data trains any public AI and no AI sits in the scoring path.

R5 · Phase 2 award uncertainty and scope creep.

Phase 1 is standalone and MK may appoint a different supplier afterward, while a feature-rich Phase 3 backlog invites MVP inflation. Mitigation: scope and price Phase 1 as a complete, handover-ready deliverable usable by any supplier; restate the out-of-scope list; confirm the MVP automates only the Snapshot and Self-Assessment Report; written change control prices additions separately.

Open decisions for the kickoff. A focused set that shapes the scoring design and the Phase 2 commercial features:
  • Exposure derivation. Is Fraud Exposure derived from the organisation profile, a dedicated question set, or both, and how should exposure and readiness combine in the priority ranking.
  • Critical-control gating. What precisely defines a failed critical control, and how should it cap maturity: a hard cap to a named band, or a graduated penalty.
  • Methodology readiness. In what form does the methodology arrive, how final are the weights and rules today, and who in MK approves a methodology version change once it is live.
  • Test-pack ownership. Does MK supply the scoring test pack with expected outcomes, or does Aveosoft co-author it from the methodology.
  • Commercial and payment model. How MK charges for the Full and Validated reports, and whether an automated South-African gateway is required at MVP or manual and invoiced access can follow.
  • Deployment and accounts. Confirm the subdomain deployment target and that all production accounts are created under MK-controlled credentials and billing.
03 Customer journey and assessment workflow · Deliverables #3, #4

From profile capture to a board-grade report

The respondent journey is designed to maximise completion of a long professional assessment while keeping the scoring honest. The organisation profile is captured first, which drives conditional applicability so each respondent only sees questions relevant to their operating model. Responses persist server-side with save-and-return, so no answer is lost if a session is interrupted on a normal South African connection.

1 Profile and applicability

The organisation profile is captured, then the engine evaluates applicability conditions to build the applicable question set. Genuinely non-applicable questions are excluded and weights are renormalised so the out-of-100 scale stays fair.

2 Assessment

The respondent works through the ten capability domains with progress, help text, and save-and-return. Each response is keyed per question with a recorded respondent, so multi-respondent contribution becomes an additive change later, not a rebuild.

3 Score and snapshot

On submit, the deterministic engine computes readiness, exposure, critical-control outcomes, the maturity band after caps, recommendations, and the full trace. The Instant Snapshot renders on-screen with readiness and exposure shown separately.

4 Report and MK workflow

On a paid or granted basis, the deterministic report generator produces the branded report. MK admins review, validate, add approved commentary, and regenerate or reissue as a new version. An anonymised benchmark record is written on completion.

The data-flow diagram below shows the end-to-end path from profile capture, through the scoring engine and its trace, to report generation, immutable storage, the MK admin dashboard, and the anonymised benchmark projection. A separate methodology side flow shows MK editing the configuration into a new version, running the test pack, and optionally recomputing history non-destructively.

Data-flow diagram: respondent journey through scoring engine to report and benchmark
04 Two implementation options · Deliverable #5

A custom build, weighed against a configured low-code platform

The real decision is not whether to write code; it is how to host a deterministic, MK-editable scoring engine so it stays transparent, owned, and able to grow. We weighed the recommended custom build against the realistic alternative the brief invites, a configured low-code assessment platform. We recommend Option A.

Evaluation areaA · Custom modular monolith + config engine (recommended)B · Configured / low-code platform
Initial costModerate, scoped to an SME MVPLowest to start
Recurring costModest, predictable managed-service linesPer-seat or per-response fees that grow with volume
User experienceFull board-grade MK brand controlConstrained by platform templates; can read as a survey
Scoring flexibilityFull: versioned config, caps and gates, dual model, tracesLimited; complex caps, gates, and dual scoring hit a ceiling
ReportingFull dynamic branded report, immutable finalsTemplated, hard to make board-grade and immutable
SecurityWe control hosting, region, encryption, RBAC for POPIADepends on the platform's posture and region
Data ownershipTotal: MK's own database, full exportOften partial, shaped by the platform
Vendor lock-inLowest: open stack, portable schemaHighest: methodology and data trapped in the platform
MaintainabilityMK self-admins; one app any competent dev can runEasy until platform limits, then blocked
ScalabilitySME to thousands without a rebuild; seams ready to splitScales, but cost scales with it
IntegrationClean subdomain, open API, webhooksOnly the platform's allowed connectors
BenchmarkingOwns the anonymised dataset, structured for the IndexData lives inside the platform; harder to own
HandoverOne codebase, schema, config, test pack, docsPlatform-specific skills, tied to the platform's longevity

Why the custom build is recommended. The brief's heaviest, repeated demands are deterministic and traceable scoring with caps and gates and a readiness-versus-exposure separation, MK self-editing without code, total data ownership and zero lock-in, board-grade branded reporting with immutable finals, and an owned dataset for future benchmarking. A configured low-code platform is the cheapest, fastest start, and the brief rightly asks us to weigh it, but it puts a ceiling on exactly what MK ranks highest, and it traps the confidential methodology and the client dataset inside a third party where leaving means a rebuild. The custom build is the only option that scores full on scoring flexibility, reporting, data ownership, lock-in, and handover at once, at a build cost that is reasonable at SME scale.

05 Recommended architecture · Deliverables #6, #7

A custom web application built as a modular monolith

We recommend a custom web application built around a versioned scoring and rules engine and an MK admin console, deployed on a dedicated MK subdomain with every account under MK-controlled credentials. The methodology lives as data, not code. This is deliberately pragmatic engineering for an SME launch: a modular application and one primary database, not an enterprise microservices estate.

FE Next.js (React) front end

Board-grade, responsive, MK-branded interface that loads well on normal South African connections, with progress, save-and-return, and conditional logic. Server rendering helps first paint and product SEO.

API NestJS API, modular monolith

One deployable with clear module seams: assessment, scoring, reporting, admin, payments, and communications. The same TypeScript language end to end keeps the team small and the handover simple.

SC In-process scoring engine

Deterministic, testable, traceable. Reads versioned configuration and emits a score plus a full trace. No black box, no model inference, no external runtime in the calculation path.

DB PostgreSQL

Relational integrity for the methodology and results, strong aggregation for the dashboard and the benchmarking dataset, fully portable, easy to export and hand over.

PDF HTML templates to branded PDF

One template path drives both the on-screen report and the PDF, with full MK control of fonts, colours, charts, and layout, and immutable final reports.

OS S3-compatible object store

Stores generated PDFs, brand assets, and later evidence uploads. Versioned, encrypted, signed-URL access, keeping issued finals immutable.

Deployment. A dedicated MK subdomain (for example score.mkfraud.co.za), not an embed or a white-labelled platform. It gives full brand control and board-grade feel, an indexable product URL, a same-root-domain trust signal under MK's certificate, all data in MK's own database, the best performance, clean independent deploys, and the lowest vendor dependency. A small call to action on www.mkfraud.co.za links across, and the subdomain is the natural base for the future client portal.
System architecture diagram: Next.js front end, NestJS modular monolith with scoring engine, PostgreSQL, object store, and supporting services
06 Proposed data model and database structure · Deliverables #8, #9

The methodology held as versioned, editable data

The data model is the structural answer to the central requirement: everything MK provides becomes rows MK can edit, not code we ship. Domains, questions, response options and values, question and category weights, applicability conditions, critical-control rules, maturity bands and caps, recommendation and strength triggers, and exposure variables all belong to a scoring configuration version with a status of draft, active, or retired.

Methodology as data. The configuration set is a first-class part of the schema, so MK edits it through the admin console rather than through a code release.
Versioned configuration. Each coherent methodology set is a version; exactly one is active for new assessments, and version history records who changed what, when, and why.
Assessment bound to its config version. A completed assessment permanently stores the version it was scored under, so an old report never silently changes when the methodology evolves.
Score result plus score trace. Each assessment carries its result and a stored JSONB trace, both exportable, capturing per-answer contributions, exclusions, and cap reasons.
Reports as versioned artifacts. Draft, final, self-assessed, or MK-validated; a final report is immutable and corrections create a new version with the prior retained.
Respondent as a first-class entity. Modelled from day one with cardinality one but designed to scale to many, so multi-respondent contribution is additive later.
Append-only audit and benchmark records. An audit trail of security and methodology actions, and an anonymised benchmark projection written on completion, kept separate from client-identifying data.
RBAC and test cases in the schema. Roles and permissions, plus stored test cases of sample responses and expected results, run through the real engine against a chosen config version.
Entity relationship diagram: organisations, assessments, responses, score results and traces, reports, scoring configuration versions, and benchmark records
07 The scoring engine and the working proof of concept · Deliverables #10, #18

Deterministic, traceable, version-controlled, and already proven in code

The scoring engine is the heart of the product. It is a pure deterministic function of the active methodology version and the applicable answers, with two separate dimensions, explicit critical-control gating, and a full trace on every run. To prove this is real rather than aspirational, we have built a runnable scoring proof of concept on the proposed Phase 2 stack, so the engine carries directly into the build.

2 Two separate dimensions, never merged

Fraud Readiness (capability across the ten domains) and Fraud Exposure (inherent opportunity from the operating model, channels, third parties, and geography) are computed by two distinct passes and presented side by side, never averaged into one number.

! A weakness cannot hide behind an average

Critical-control questions are flagged; maturity caps are explicit rules. A failed critical control caps the maturity band regardless of a healthy average, force-lists the gap, and pushes it up the priority ranking.

T Full score trace

Every run records each answer's value and weight, its contribution to the domain, the overall roll-up, the critical-control evaluation, the maturity decision before and after caps, and which questions were excluded as not applicable and why.

QA Expected-versus-actual test pack

Named sample response sets with MK-approved expected results run through the real engine and produce a field-level difference report. The launch gate: no production launch until scoring reconciles against the approved test cases.

The proof of concept is real, runnable Node code. It implements the exact scoring design specified in this pack: the configuration data model, the two-model readiness and exposure separation, critical-control gating, the score trace, and the test-pack mechanism. It runs on Node with a JSON methodology configuration, mirroring the proposed Node and PostgreSQL stack with zero proprietary rules engine in the path, and ships with a fourteen-case expected-versus-actual test pack (ten scoring cases and four report cases). The methodology values inside it are an illustrative sample; MK provides the real methodology.

Live proof of concept · Sample run

Sample Holdings (Pty) Ltd scored 61.25 / 100, capped to Developing, against Severe exposure

Financial services · methodology sample-v1 (illustrative) · readiness and exposure shown separately

The sample organisation's weighted readiness score of 61.25 alone would read as the Established band. The engine caps it to Developing because the independent, confidential whistleblowing critical control failed: a high average cannot mask the gap. Fraud Exposure is 75 / 100, the Severe level, which combined with only Developing readiness automatically triggers a priority intervention recommendation. The engine emits a full per-domain and per-answer trace explaining the cap, the exclusions, and every contribution.

61.25Readiness / 100
DevelopingBand after cap
75Exposure / 100 (Severe)
14Test cases pass

Per-domain readiness breakdown from the sample run. The two failed domains, Whistleblowing & Reporting and Data, Analytics & Monitoring, both score 37.5, and the whistleblowing failure is the critical control that drives the maturity cap.

Capability domainScore / 100Note
Governance & Fraud Risk Ownership75Board-approved fraud risk policy critical control passed
Fraud Risk Assessment62.5
Preventive Controls75
Detective Controls62.5
Whistleblowing & Reporting37.5Independent, confidential whistleblowing critical control failed: drives the cap
Investigation & Response50
Third-Party & Vendor Risk62.5
Data, Analytics & Monitoring37.5Lowest-scoring capability alongside whistleblowing
Culture, Awareness & Training75
Policy & Regulatory Compliance75
Why this matters. This single sample run demonstrates, in working code, every promise the brief treats as make-or-break: a deterministic calculation, readiness and exposure kept separate, a critical-control failure capping the band so a weakness cannot be averaged away, an automatic priority-intervention recommendation, and a full trace MK can read and export. The same engine is directly reusable in the Phase 2 build.
08 Report generation method · Deliverable #10

Board-grade reports from controlled MK content

Reports are assembled from MK-approved material only, generated deterministically from the scoring result, the trace, and the organisation profile. There is no unrestricted AI making risk decisions or inventing recommendations. A single HTML and CSS template set drives both the on-screen report and the PDF render, so MK gets full brand fidelity in both surfaces and there is one place to maintain.

Conditional content blocks driven by the same trigger rules as the recommendations, so a critical-control gaps section appears only when gaps exist.
Score-based interpretation pulled from MK's interpretation library by maturity band and exposure level, never generated freely.
Dynamic charts and a priority ranking, a 30, 60, and 90-day action plan from MK's pre-approved items, and sector-specific recommendations.
Disclaimers including the mandatory statement that a self-assessed report is based on respondent-supplied information and not independently verified.
Versioning and immutability. Every report is a versioned artifact labelled draft, final, self-assessed, or MK-validated. Once marked final and issued it is immutable in object storage; corrections create a new version with the prior retained and the change recorded, so there are no silent changes to issued finals. Each report stores the methodology version it was generated under, so a reissue can faithfully reproduce the original or knowingly regenerate under a newer methodology. Any optional AI assistance is an off-by-default drafting aid on MK-approved commentary, outside the scoring and report-content pipeline, under a no-training agreement, and structurally unable to alter a number or invent a recommendation.
09 Security and access approach · Deliverable #11

A POPIA-aligned security and access design

The Protection of Personal Information Act is the relevant frame, and the platform is designed to it from the start. All production accounts are created under MK-controlled credentials and billing, so MK owns the system and Aveosoft holds working access only.

Hosting in a South-Africa-appropriate region with a defensible POPIA posture, all accounts under MK control
Encryption in transit (TLS 1.2 or higher) and at rest (AES-256) for the database, backups, and object storage
Multi-factor authentication for MK admin and reviewer accounts; respondent access kept light to protect completion
Role-based access (Respondent, Admin, Reviewer, Super Admin), enforced server-side on every privileged action
Automated daily backups, point-in-time recovery, and a documented restore runbook
An append-only audit trail of security and methodology actions, with logs scrubbed of unnecessary personal data
Configurable retention and account deletion supporting POPIA data-subject rights
Incident handling aligned to POPIA breach-notification duties, and full data export at any time
No public-AI training on MK data. The deterministic engine never sends data to any AI service, and no generative AI sits in the scoring path. Sensitive client and methodology information is never used to train public AI models. The only optional AI feature is an off-by-default drafting aid on MK-approved content, operated under a no-training data processing agreement.
10 Third-party services, recurring cost, vendor lock-in · Deliverables #12, #13, #14

Low, predictable running cost; lock-in only to open technology

Each third party is a commodity service with a drop-in alternative, configured under MK-owned accounts. The figures below are rough monthly estimates in USD for an SME launch, confirmed during the build phase. The custom architecture carries no mandatory per-seat or per-assessment platform licence.

ServiceProvider examplesMonthly (USD est.)
App and database hostingManaged app host plus managed PostgreSQL40 to 80
Object and file storageS3-compatible5 to 15
Transactional emailPostmark or Amazon SES0 to 15
Report generationRuns in the application tier0
AnalyticsPrivacy-respecting analytics0 to 15
Domain, DNS, TLSMK registrar plus managed TLS1 to 5
Backups and monitoringAutomated backups, uptime monitoring5 to 20
PaymentsPayFast, Yoco, or Peach PaymentsPer-transaction; no fixed monthly
Indicative total at launchPredictable, grows gently with volume~75 to 120 / mo

Vendor lock-in is low by design. The stack is open and standard (React, Node, PostgreSQL, HTML to PDF), with no proprietary runtime holding the methodology or data. Every third party is swappable behind a thin adapter: PostgreSQL is portable across providers, object storage is S3-compatible, and email, payment, and analytics providers are commodities. Full data export of raw responses, scores, traces, reports, and configuration means MK can leave any provider or hand the whole system to another competent developer with the code, schema, scoring configuration, report templates, and test pack in hand. The only lock-in is to open, widely supported technology, which is the desirable kind. A low-code platform, by contrast, would hold the confidential methodology and the client dataset inside a third party where leaving means a rebuild.

11 Implementation roadmap · Deliverables #15, #16

A paid Phase 1, then a milestone-funded MVP build

Phase 1 is a standalone, handover-ready deliverable. Phase 2 builds the MVP under milestone acceptance, with the fixed price confirmed at the close of Phase 1 once requirements are validated. Phase 3 enhancements follow by milestone as MK chooses.

Phase 1 · 3 to 4 weeks · USD 1,475 fixed

Solution design, prototype, and scoring proof of concept

This pack: requirements validation, the assumptions and risk register, the customer-journey and workflow design, two implementation options and the recommended architecture with diagrams and database structure, the security, recurring-cost, and vendor-lock-in assessments, the implementation roadmap, the fixed-price build proposal, a clickable prototype, and the demonstrated sample score and report.

Phase 2 · ~6 to 9 weeks · USD 8,000 to 12,000

MVP build

The assessment interface, organisation profile, conditional logic, and save-and-return; the scoring engine with category and maturity rules, the exposure profile, and critical-control logic; the MK admin console; the snapshot results; full report generation; email workflows; basic payment and access control; data export; subdomain deployment; analytics; testing; documentation; training; and production launch. The single fixed price is confirmed at the close of Phase 1.

Phase 3 · Later, by milestone

Enhancements

Multi-respondent assessments, client accounts and portals, evidence uploads, the MK validation workflow, reassessment comparison, benchmarking, dashboards, subscriptions, additional sector modules, API integrations, and the annual Fraud Readiness Index.

Phase 2 milestone acceptance. The build is structured into evidence-based milestones: requirements and architecture (MK approval of the validated spec), prototype and scoring proof of concept (agreed test responses produce expected scores), assessment and administration build (functional test cases pass), reporting and commercial workflow (reports match approved content and calculations), deployment and testing (end-to-end journey completes), and documentation and handover (successful handover, training, and credential transfer). Acceptance is bound to the agreed scoring test pack and functional test cases, so it is evidence-based rather than opinion-based.
12 Deliverable checklist and recommended next step

Every Section 10 deliverable, and where it is evidenced

This pack evidences the Phase 1 design deliverables. The clickable prototype and the scoring proof of concept are live artifacts delivered alongside this document. The table maps all eighteen items to where each is evidenced.

#Section 10 Phase 1 deliverableWhere it is evidenced
1Requirements validationSection 01 of this pack
2Assumptions, risks, open decisionsSection 02 of this pack
3Customer-journey designSection 03 of this pack
4Assessment and report workflowSection 03 of this pack and the data-flow diagram
5Two viable implementation optionsSection 04 of this pack
6Recommended technical architectureSection 05 of this pack
7Architecture diagramSection 05, embedded diagram
8Data-flow diagramSection 03, embedded diagram
9Proposed database structureSection 06 of this pack and the ERD
10Proposed report-generation methodSections 07 and 08 of this pack
11Security and access approachSection 09 of this pack
12Third-party platform assessmentSection 10 of this pack
13Recurring cost estimateSection 10 of this pack
14Vendor-lock-in assessmentSection 10 of this pack
15Implementation roadmapSection 11 of this pack
16Fixed-price build proposalSection 11 of this pack (USD 8,000 to 12,000, confirmed at close of Phase 1)
17Clickable prototypeSeparate live artifact, delivered alongside this pack
18Demonstration of a sample score and reportSection 07; the runnable scoring proof of concept, a separate live artifact
1
Review this pack and confirm the open decisions

The six items in Section 02 shape the scoring design and the Phase 2 commercial features.

2
Provide the methodology pack under a signed confidentiality arrangement

We are ready to sign so MK can share the questions, weights, maturity bands, critical-control rules, exposure variables, and recommendation library that replace the illustrative sample.

3
Confirm the Phase 2 fixed price and proceed to the MVP build

With requirements validated, the single fixed Phase 2 price is confirmed and the build proceeds under milestone acceptance, carrying the proven scoring engine directly forward.

By the close of Phase 1 MK holds validated requirements, a recommended architecture with diagrams and database structure, the security, recurring-cost, and vendor-lock-in assessments, an implementation roadmap, a fixed-price build proposal, a clickable prototype, and a demonstrated and runnable sample score and report. That pack is valuable on its own and it is the strongest possible basis for the Phase 2 build.