AZRAEL — COMPREHENSIVE PROJECT DOSSIER Investor, Technical, and Family Briefing Prepared October 22, 2026

Prepared for prospective investors, collaborators, and Ruth. Founder/operator: Shaun. This is a project briefing, not an audited prospectus, securities offering, or guarantee of performance.

HOW TO READ THIS DOCUMENT

Evidence labels: DEMONSTRATED: The founder has observed or exercised a working function. ENGINEER-REPORTED: A coding agent claims implementation or testing, without independent end-to-end acceptance. IN DEVELOPMENT: An active integration or unfinished feature. PLANNED: A product or business capability not yet proven.

Do not confuse these categories. This distinction is essential to understanding Azrael accurately.

======================================================================

1.  EXECUTIVE SUMMARY

Azrael is a developing AI-powered operations and software-production ecosystem. The ultimate goal is not merely to converse with an AI assistant. It is to let one operator supervise a network of specialized AI coding workers, cloud services, media-production tools, websites, and customer delivery systems from an Android phone.

The intended commercial workflow is: a customer describes a software or website project; Azrael clarifies requirements, calculates a high-end inference estimate, generates a deposit link, receives payment confirmation, assigns work to its engineering agents, tests the resulting software, and delivers the finished product through Dropbox or an approved hosting environment. Shaun oversees the process through an owner-only Azrael Master APK.

The project has real components: a local Windows AI stack; multiple active OpenCode coding sessions; an OVH cloud environment; a publicly reachable ProfessorShaun website; Android APK prototypes; video generation and at least one published video; and engineer-created integration code and reports.

The complete unattended, paid, multi-customer production cycle has NOT been verified. Nor has the full phone-to-cloud-to-Windows engineer command loop been demonstrated as reliably operational. The immediate priority is to connect existing components and produce an installable, tested Master APK.

Azrael’s strategic proposition is the integration of AI development, operational control, cloud coordination, automated digital production, and verified fulfillment at relatively low infrastructure cost. Its investment case depends on converting this prototype footprint into secure, repeatable customer outcomes and sustainable economics.

======================================================================

2.  VISION AND DESIGN PHILOSOPHY

Shaun wants Azrael to operate as an AI-directed digital production business. Instead of manually coding each program, watching every terminal, or checking each server, he wants to set goals, authorize consequential actions, and receive trustworthy results.

Principles: - Intent-first execution: solve the actual requested problem. - Evidence before claims: agent statements alone are not proof. - Consumer-visible tests: verify real devices, real endpoints, and real deliverables. - Separate control, inference, execution, and customer interfaces. - Keep persistent logs, histories, job states, costs, and recovery checkpoints. - Give each engineer clear project ownership and limited permissions. - Protect customer data and require approvals for sensitive actions. - Optimize for reliable unattended work, not merely high agent activity. - Keep fixed overhead low and scale capacity only when justified.

The founder has described this as a transition from feature-building to systems management. The objective is freedom from constant laptop supervision, not a system that requires continual personal attention.

======================================================================

3.  THE ARCHITECTURE

OWNER OR CUSTOMER -> Android Azrael Master APK or customer website -> Azrael Cloud authenticated API and orchestration -> Task queue, approvals, account and credit ledger -> Windows or production-server OpenCode workers -> Hosted inference providers and suitable local AI models -> Code, websites, video, tests, packages -> Verified delivery via Dropbox or hosted deployment -> Completion report and audit history

Historical product planning distinguishes an owner-only Master APK, a public bilingual Android Personal product, a Windows Local Developer product, department-specific toolkits, and independent cloud services. These are architectural directions, not evidence of five completed products.

The control plane must remain responsive while workers execute heavy jobs. Every remote command should have a target, authenticated origin, unique identifier, delivery acknowledgment, actual result, and timeout/error state. A plausible chatbot response is not proof that the requested action occurred.

======================================================================

4.  LOCAL WINDOWS AZRAEL

DEMONSTRATED/OBSERVED: - A Windows 11 laptop with approximately 16 GB RAM runs local Ollama/Qwen and Open WebUI components. - The founder has conversed with the local AI assistant. - Some Windows music playback/control actions were tested successfully. - Several independent OpenCode coding agents have operated concurrently, producing code, reports, and tests.

ENGINEER-REPORTED/IN DEVELOPMENT: - Wake-word voice interaction, local speech recognition, text-to-speech, and a Windows tools bridge. - Web access and desktop actions. - Persistent timestamped voice transcripts and continuity. - Startup and recovery on reboot. - Stable volume/media controls and single-owner TTS output.

Historical problems include intermittent speech recognition failures, overlapping voice outputs, incomplete transcripts, unreliable internet research, and commands that did not reach the intended tools. Reported fixes should be re-tested, not assumed.

The laptop has an 11th-generation Intel i5-class CPU, integrated graphics, approximately 16 GB RAM, and local storage. It is useful for coding agents and smaller models, but memory-intensive Android builds or concurrent local inference can constrain throughput.

======================================================================

5.  OPENCODE: THE ENGINEERING WORKFORCE

Azrael’s engineers are separate OpenCode sessions assigned to specialized projects: Android Master, cloud services, YouTube production, websites, and observation/integration.

These agents can write and edit source code, run tests, diagnose errors, create reports, and prepare deliverables. Their reports are valuable evidence, but must be checked against actual output and real-world tests.

The proposed OpenCode Observer is a READ-ONLY monitoring component that discovers real sessions, associated projects, last activity, task progress, errors, commits, tests, and blockers. It must distinguish OS processes from OpenCode sessions and from bridge workers. A previously displayed ‘81 sessions / 3 active’ figure appeared in a test example and is not proof of current live session counts.

A previous engineering screenshot showed Observer artifacts including docs/DISCOVERY_REPORT.md and state/reports/workforce.md. At that point the cloud telemetry receiver /v1/opencode/telemetry was not yet complete, and the Observer was in temporary mirror mode.

The intended remote functions are: list real engineers, inspect tasks, send scoped instructions to a selected session, run approved tests, request status, pause/cancel supported work, and receive verifiable completion reports. These must not expose an unrestricted public remote shell.

The founder’s priority is coordination and verified execution, not multiplying agents for its own sake.

======================================================================

6.  AZRAEL CLOUD AND EXISTING OVH SERVER

The existing OVH VPS has been described as approximately 2 vCPU, 4 GB RAM, 40 GB storage, Ubuntu Linux, with IP 40.160.149.243. Reported components include Caddy HTTPS, a Python API, and systemd services azrael-api and azrael-sweep.

Cloud engineering reports mention task routing, model fallback, authenticated interfaces, versioned releases, and automated tests. A prior report claimed 62/62 tests passed; this is engineer-reported rather than independently audited acceptance.

DEMONSTRATED: A public ProfessorShaun website has been served from the existing infrastructure and personally viewed by the founder.

TARGET CLOUD RESPONSIBILITIES: - Authenticate owner, workers, and eventual customers. - Maintain durable queues, worker heartbeats, and command/event history. - Route AI requests to suitable providers and local workers. - Hold customer job state, credits, estimates, and payment events. - Connect Android Master to Windows and future production workers. - Expose reliable status and alerts. - Coordinate approved deployment and Dropbox delivery.

The current VPS should be the control plane, not the default location for heavy, untrusted customer compilation.

======================================================================

7.  AZRAEL MASTER ANDROID APK

DEMONSTRATED: The founder installed Android Master builds on a Samsung Galaxy S24+-class device and tested some voice/cloud interaction.

ENGINEER-REPORTED: Builds labeled 1.4 through 1.7.x, natural-language task routing, status interfaces, and integration changes. Version labels and successful builds alone do not establish a finished system.

KNOWN GAPS OBSERVED IN ENGINEERING WORK: - ‘Play Tori Amos on my computer’ failed because the command did not route to a Windows media tool. - OpenCode session counts were initially confused with bridge worker counts. - Raw task JSON appeared in user-facing notifications. - Cloud telemetry and actual session inventory required further integration. - At least one Gradle build error appeared in a screenshot; the root cause was not visible.

REQUIRED FINAL MASTER EXPERIENCE: - English/Spanish interfaces where applicable. - Voice and text commands. - Actual engineer/session inventory, status, tasks, and blockers. - Cloud, Windows, and production-worker health. - Scoped commands with acknowledgment and verified result. - YouTube production and approval status. - Website/hosting operations, account integrations, and delivery history. - Inference usage, credits, deposits, and alerts. - Offline/stale indicators, searchable activity, and secure authentication.

IMMEDIATE NEXT ENGINEERING ASSIGNMENT: When Shaun returns home and authorizes it, he intends to create ONE NEW independent OpenCode integration coordinator. Its first action must be to contact the existing Cloud and Android APK engineers, retrieve their latest notes and worklogs, establish a REAL coordination channel, and reconcile their interfaces. It must then coordinate unattended integration, build, testing, and packaging, respecting other engineers’ code ownership.

The REQUIRED deliverable is a prepared, installable Azrael Master APK with real end-to-end acceptance evidence, not merely a plan, report, or source-code change. The directive itself has been deliberately deferred until Shaun is home.

======================================================================

8.  VIDEO PRODUCTION, VOICE, AND YOUTUBE

DEMONSTRATED: Azrael’s Windows video workflow can produce narrated slideshow-style MP4 output, and at least one automatically produced video was published to YouTube.

IMPORTANT FAILURE: A published video used the wrong voice. The founder requires his authorized voice to be used for owner-narrated videos, with verification rather than silent substitution.

ENGINEER-REPORTED/IN DEVELOPMENT: - Automated scripts, rendering checkpoints, vertical Shorts, and longer productions. - English and Spanish narration. - Voice cloning/reference samples and speaker-similarity checks. - Upload controls that block unverified or incorrect voices. - Render progress, ETA ranges, and mobile status.

In a recent screenshot, a longer bilingual production was rendering and speaker-similarity threshold calibration was deferred. Therefore, implemented safeguards must not be described as fully verified until actual positive and negative tests pass.

COMMERCIAL APPLICATIONS: Short videos, product explainers, bilingual promotional material, custom narration, and recurring content services. Voice cloning must require the speaker’s authorization. Publishing, copyright, and platform compliance require explicit controls.

======================================================================

9.  WEBSITE CREATION, DOMAINS, AND HOSTING

DEMONSTRATED: The ProfessorShaun website was deployed at a temporary sslip.io hostname on the OVH VPS. Shaun visited it and reported that it looked good.

ENGINEER-REPORTED: HTTPS via Caddy, YouTube video and Shorts feeds, periodic refresh, watchdog monitoring, rollback, and deployment artifacts.

DOMAIN WORK: Shaun has a domain webca.app intended as a hub, with professorshaun.webca.app for the site. Google Cloud DNS and valid HTTPS configuration are part of the integration. Exact current deployment status should be verified.

NAMECHEAP: A screenshot showed three active domains—alternativeprofileslive.world, alternativeprofileslocal.world, and angelfaces.lat—with privacy protection. The website creator engineer, called Azriel Bot, owns the Namecheap integration, including authorized account connection, DNS and domain management. The new Master APK coordinator should consume its approved interface, not duplicate or take over that work.

FUTURE AZRAEL PAGES: A self-service landing-page/website builder, branded URLs, QR codes, optional custom domains, and centrally managed mainstream advertising. Multi-tenant security, quotas, abuse protection, backups, domain lifecycle, and legal disclosures remain to be built and verified.

ADVERTISING: ExoClick integration and website verification have been explored, but possession of an ad account or snippet does not prove approved placements or income. Affiliate traffic dashboards showed referrals and uniques, not proven paid conversions.

======================================================================

10. BLUESKY AND SOCIAL PUBLISHING

Shaun reports that the Bluesky posting system is completed and is more important than bulk profile editing. This is founder-reported status, not a separately documented live audit here.

A standalone bulk profile manager for authorized accounts has been planned, potentially built with Gemini or Codex. It would read bluesky_accounts.csv from a folder Shaun has not yet selected, use secure credential references, preview bulk edits, update permitted profile fields, verify read-back, and report failures. It is explicitly DEFERRED and should not distract from Master APK integration.

Any commercial social publishing must respect authorization, platform rate limits, anti-spam policies, and customer consent.

======================================================================

11. DROPBOX DELIVERY AND CUSTOMER ARTIFACTS

Dropbox is intended as the final delivery layer for generated websites, ZIP archives, Python tools, Windows installers, Android APKs, and engineering handoffs. Some internal project handoffs and artifacts have reportedly been saved there.

A reliable commercial workflow should use authenticated Dropbox APIs rather than assuming a particular local synced directory exists.

Every customer artifact should have a job ID, source revision, build/test report, checksum, customer-specific permissions, delivery link, and retention policy. Uploading a file is not proof that it runs correctly. Customer files and secrets must remain isolated.

======================================================================

12. BUSINESS MODEL: AI-OPERATED SOFTWARE AGENCY

The proposed customer experience: 1. Customer describes a project on an Azrael website. 2. Azrael clarifies requirements, deliverables, exclusions, and review criteria. 3. Azrael estimates high-end inference usage and calculates the required deposit. 4. Customer receives a payment link. 5. Server verifies payment before starting funded work. 6. Cloud assigns work to isolated coding agents. 7. Agents create code, run tests, package the result, and report limitations. 8. Owner or authorized customer approves where needed. 9. Azrael delivers via Dropbox or an approved deployment. 10. Final usage statement, support instructions, and job history are retained.

Potential offerings include small-business websites, Python scripts, Windows tools, Android APKs, AI assistants, business workflow automation, integrations, managed hosting, video production, and ongoing software maintenance.

This is a BUSINESS PLAN, not an already proven self-service commercial system. No completed paid customer quote-to-delivery cycle has been established in the available record.

======================================================================

13. PRICING AND PAYMENT DESIGN

Shaun’s specified rule:

PROJECT CHARGE = (HIGH-END ESTIMATED INFERENCE COST x 10) + $19.99 SETUP FEE.

The 10x inference rate also applies to local/self-hosted model calls, using an equivalent published commercial inference rate as the pricing benchmark. The benchmarked selling price is NOT the same as actual electricity, hardware, or provider expense.

ILLUSTRATIVE QUOTES: - $2 high-end inference estimate: $20 + $19.99 = $39.99. - $10 high-end inference estimate: $100 + $19.99 = $119.99. - $25 high-end inference estimate: $250 + $19.99 = $269.99. - $50 high-end inference estimate: $500 + $19.99 = $519.99.

Azrael should show transparent assumptions, included scope, available credit, refund/cancellation rules, additional-deposit conditions, and the status of the payment. A payment service such as Stripe could generate checkout links when authorized; payment must be confirmed server-side.

A separate ledger must record each inference call, provider/model, token or compute usage, rate, customer/job, actual cost, billed amount, and credit balance. Paid and local inference need consistent metering.

The 10x multiplier is MARKUP, not a guarantee of profit. Costs also include failed jobs, retries, revisions, support, taxes, payment fees, hosting, storage, security, and customer acquisition. No audited revenues, margins, paying customer totals, or investor returns are established in this dossier.

======================================================================

14. COMPUTE CAPACITY AND SECOND OVH VPS

CURRENT: - OVH control server: approximately 2 vCPU / 4 GB RAM / 40 GB storage. - Windows laptop: approximately 16 GB RAM, local Qwen/Ollama, OpenCode. - Hosted model inference through Hugging Face-linked providers.

PROPOSED: - Second OVH VPS-3 production worker, discussed at approximately 6 vCores, 12 GB RAM, 100 GB NVMe, and $12.32/month. This is a previously discussed advertised price, NOT a verified current checkout price or proof of purchase.

The existing VPS’s exact bill is unconfirmed. Recent conversation estimated $7–$8/month; an older plan quoted about $5.35. At the $7–$8 estimate plus $12.32, combined VPS spending would be approximately $19.32–$20.32 before taxes and other charges. A guaranteed sub-$20 total cannot be claimed.

PLANNED DIVISION: Server 1 = identity, API, coordination, credits, queues, phone status. Server 2 = isolated customer builds, coding workers, tests, packaging. Windows laptop = additional worker and suitable local inference.

Earlier rough planning suggested 3–5 simultaneous mixed jobs initially, with more lightweight websites and fewer heavy APK/video builds. Those are NOT measured benchmarks. Real concurrency depends on CPU/RAM, build requirements, model latency, and failure/retry behavior. The system may queue many orders without executing them simultaneously.

Do not purchase capacity solely on estimates. First establish secure dispatch and measure actual workloads.

======================================================================

15. AI INFERENCE AND OPERATING COSTS

The system has used Hugging Face-connected inference providers including DeepInfra and Featherless AI, with Nscale appearing in billing data. A screenshot showed 4,824 requests and approximately $17.06 for a measured request set; later billing screenshots showed account period usage around $20.48 and approximately $4.52 in remaining credits. These are point-in-time figures, not a reconciled accounting report. Automatic recharge appeared disabled.

Inference costs can fluctuate sharply when many agents work simultaneously. The platform needs per-job budgets, provider limits, model routing, error classification, transparent credits, and alerts. Unattended engineers must not silently spend beyond approved limits.

Commercial pricing should account for all real expenses, not only AI token charges. Local inference is not free: it consumes electricity, hardware capacity, time, and maintenance.

======================================================================

16. SECURITY, PERMISSIONS, AND OPERATIONAL GOVERNANCE

A system with access to Windows computers, cloud servers, domain registrars, publishing accounts, voice samples, customer files, and payment links needs strict controls.

Required safeguards: - Strong owner authentication and MFA where supported. - Per-worker scoped credentials stored securely, never in chat logs. - Customer-specific identity, workspaces, storage, and permissions. - Audited commands with explicit target, authorization, and result. - Owner approval for purchases, transfers, destructive changes, and sensitive publication. - Secure outbound worker-to-cloud communication; no exposed general shell. - Encrypted connections, key rotation, backups, and recovery testing. - Consent for voice cloning and appropriate synthetic media disclosures. - Dependency licensing, vulnerability scanning, and software provenance. - Abuse controls for hosted sites and publishing. - Customer data deletion, support, refund, and incident processes.

The OpenCode Observer should remain read-only. An engineer should not approve its own risky operations, change customer balances without audit, or access unrelated accounts. Azriel Bot owns the Namecheap integration; the Master coordinator should not assume those privileges.

======================================================================

17. WHAT COUNTS AS A FINISHED DELIVERABLE?

A customer project should have: - Written requirements and exclusions. - Approved funding and job ID. - Reproducible source revision and dependency list. - Build and test logs. - Security/secret checks. - Functional acceptance evidence. - Artifact checksum and delivery link. - Known limitations and user instructions. - Final verified, failed, blocked, or review-needed status.

For the MASTER APK specifically, acceptance means: - Install the actual APK on the target Android phone. - Authenticate to the real cloud. - Show actual Windows/OpenCode sessions, not invented counts. - Send a scoped command to the correct engineer. - Receive real delivery acknowledgment and completion result. - Show offline/stale/error states correctly. - Recover from interrupted connections. - Preserve event history and not expose secrets.

A passing mock test or successful compilation is necessary but not sufficient.

======================================================================

18. RISKS AND MITIGATIONS

INTEGRATION: Independent engineers may use incompatible interfaces. Mitigation: one coordinator, shared contracts, live tests.

RELIABILITY: Agents may stall or claim false completion. Mitigation: durable queues, watchdogs, read-back checks, independent verification.

SECURITY: Remote code execution and customer data are sensitive. Mitigation: least privilege, isolation, approval gates, audit logs, security review.

RESOURCE LIMITS: 4 GB cloud VPS, 16 GB laptop, and prospective 12 GB production VPS are finite. Mitigation: queues, quotas, measured load tests.

COST OVERRUN: Inference is only part of production cost. Mitigation: per-job budgets, real cost ledger, controlled retries and revisions.

PLATFORM DEPENDENCE: Model providers, YouTube, Bluesky, DNS, Dropbox, and ad networks can change APIs/policies. Mitigation: documented adapters, monitoring, compliant usage.

CUSTOMER QUALITY: Generated software may contain defects. Mitigation: acceptance testing, review, support and refund terms.

COMMERCIAL UNCERTAINTY: Technical progress does not guarantee paying customers. Mitigation: narrowly scoped paid pilots and measured economics.

FOUNDER DEPENDENCE: Many decisions remain centralized. Mitigation: documentation, runbooks, delegated permissions, and reproducible recovery.

======================================================================

19. DEVELOPMENT ROADMAP

PHASE ONE — MOBILE CONTROL (IMMEDIATE) - Create one new integration coordinator only when Shaun is home and ready. - Have that coordinator contact Cloud and APK engineers first. - Obtain real notes, latest status, interfaces, and blockers. - Complete Windows Observer to Cloud telemetry. - Expose real engineer status and scoped commands in Android. - Build, install, and verify the Master APK. - Produce the APK itself as the deliverable, not only notes.

PHASE TWO — HARDEN CURRENT PRODUCTS - Complete voice-identity verification and safe YouTube publishing. - Confirm Bluesky authorized posting status. - Finalize website/domain integrations under the correct engineer. - Secure Dropbox packaging and delivery. - Add restart recovery, backups, health reports, and spending alerts.

PHASE THREE — PRODUCTION CAPACITY - Confirm OVH costs and decide on VPS-3 purchase. - Build isolated production worker environments. - Add authenticated job dispatch and quotas. - Benchmark concurrency and cost per finished job.

PHASE FOUR — FIRST COMMERCIAL PILOT - Select a narrow, deliverable-based service. - Define scope, price, deposit, and acceptance criteria. - Complete one actual customer-style job end to end. - Measure time, costs, revisions, defects, and customer experience.

PHASE FIVE — SCALE - Customer portal, roles, payment reconciliation, billing statements. - More templates and repeatable products. - Multi-tenant security and support. - Subscription hosting and maintenance. - Expand worker capacity only with measured demand.

A Sunday mobile-control milestone was discussed as an ambitious hope, not a confirmed release date.

======================================================================

20. INVESTOR ASSESSMENT

CURRENT ASSETS: - Founder-directed technical architecture. - Local Windows assistant and multiple AI coding sessions. - OVH cloud infrastructure and deployed website. - Android Master prototypes. - Video-generation and publication evidence. - Domain and delivery integration work. - Defined pricing hypothesis and commercial workflow.

WHAT COULD BECOME DIFFERENTIATED: - Unified mobile control over AI coding, hosting, media, and fulfillment. - Low fixed overhead with scalable worker-based execution. - Measured, auditable project completion rather than chatbot-only access. - Reusable software services, hosting, and maintenance revenue.

NOT YET PROVEN: - Complete unattended integration. - Production-grade security and multi-tenant isolation. - Verified customer payment-to-delivery flow. - Sustained customer demand and retention. - Unit economics, profitability, or enterprise reliability. - Fully tested owner Master APK.

A serious investor should seek a live end-to-end demonstration, repository and IP audit, expense invoices, verified build/test artifacts, customer evidence, and a realistic plan for capital deployment.

This dossier does not claim a legal entity, valuation, equity structure, existing funding round, audited revenue, or projected return.

======================================================================

21. EXPLANATION FOR RUTH — IN EVERYDAY LANGUAGE

Azrael is the AI system Shaun has been building. It is not just one program. It is a collection of connected tools that Shaun hopes will eventually work like a small digital company.

At home, his Windows computer can run AI coding assistants. He also has a cloud server on the internet, an Android app under development, a website creator, a video producer, and tools for handling online services. Each part has a different responsibility.

Some things already work. Shaun has talked to the local assistant, run multiple AI engineers, seen a website online, tested Android versions, and had a video produced and published. Other things are unfinished. In particular, he still needs the phone app, cloud, and coding workers to communicate reliably.

The goal is for Shaun to be able to use his phone to tell Azrael to create a website, application, or automation for a customer. Azrael would calculate the price, collect a deposit through a secure payment service, have its AI engineers do the work, test the result, and deliver the finished files through Dropbox.

Shaun wants to manage this from anywhere, rather than sit at his laptop all day. He is excited because the system could eventually provide paid digital services without requiring him to personally write every line of code.

This does not mean the business is already finished or earning money. The individual tools are progressing, but connecting and testing them is the next major step. AI engineers sometimes report that something is done before Shaun has verified it, so accurate testing matters.

The planned pricing is ten times the high-end estimated AI inference cost, plus a $19.99 setup fee. This is a planned pricing system, not guaranteed profit. Hosting, customer support, revisions, and other expenses still count.

Most importantly, the purpose of Azrael is to give Shaun more freedom. It should eventually allow him to rest, eat, spend time with Ruth, and live his life while reliable systems continue working. Getting enough sleep is part of good engineering judgment: a rested brain thinks better.

======================================================================

22. NOTES FOR ANOTHER CHATGPT THAT READS THIS FILE

If Ruth pastes this document into ChatGPT: - Explain the project in plain language, without assuming technical knowledge. - Distinguish what works from what engineers merely reported. - Do not invent a finished business, income, security certification, or release date. - Azrael is the project; Azriel/Azreal are sometimes dictation variants. - Shaun is the founder and Ruth is his wife. - The immediate priority is one verified, installable Master APK. - A new OpenCode coordinator should first communicate with existing Cloud and APK engineers, then work toward that deliverable. - Azriel Bot owns Namecheap and website-creator integration. - Bluesky bulk profile editing is deferred; posting is reported done. - The second OVH VPS-3 is proposed, not confirmed purchased. - The pricing/deposit system is planned, not established customer revenue. - Be encouraging without hiding technical, financial, or operational uncertainties.

======================================================================

23. INFORMATION NEEDED BEFORE FORMAL FUNDRAISING

Collect the following before presenting this as a formal investment prospectus: - Legal entity and ownership structure. - IP assignments, software/model licenses, and repository inventory. - Verified deployed endpoint and security architecture. - APK install demo and live end-to-end command trace. - Actual OVH, domain, inference, storage, and other invoices. - Measured throughput and cost per customer deliverable. - Customer contracts, invoices, deposits, revenue, churn, and testimonials if any. - Privacy/security policies and customer terms. - Competitor research and evidence of market demand. - Capital requirements, milestones, and realistic use of proceeds.

FINAL ASSESSMENT

Azrael is a rapidly evolving modular AI operations and digital production project with tangible technical progress and an ambitious commercial direction. Its strongest immediate opportunity is not adding unlimited new features; it is proving one dependable chain from mobile instruction to cloud dispatch, engineering execution, tested artifact, and authorized delivery.

If that sequence becomes secure, repeatable, and economically viable, Azrael could support a lean software-development and digital-services business. Until then, it should be represented as an advanced prototype ecosystem, not a finished autonomous company.

END — OCTOBER 22, 2026