portfolio/.project/ARCHITECTURE.md

Autonomous Enterprise Portfolio

Initial architecture

Document: ARCHITECTURE.md
Status: First draft — conceptual architecture; not an implementation specification
Established: September 16, 2026
Owner / architecture authority: Ken Schaefer
Companion documents: VISION.md · PORTFOLIO.md · PROJECT-PLAN.md

Build once. Launch rapidly. Validate with a sale. Operate, replicate, or sell.

1. Purpose and scope

This document describes the business factory that supports a portfolio of complementary, AI-enabled ventures. The factory provides reusable capabilities; each venture retains a clear identity, its own commercial hypothesis, and a practical path to independent operation, licensing, sale, or retirement.

The architecture must help us test whether AI and assets already under our control can compress time to launch, time to first sale, incremental capital, and required routine owner labor. It is not a prerequisite to building the first venture. We will implement only the boundaries and capabilities required by active experiments, then extract reusable parts from working solutions.

In scope: portfolio and venture boundaries; shared business services; responsibilities and authorization; information, evidence, and financial attribution; integration and deployment patterns; lifecycle, portability, and migration; first two proofs of concept.

Out of scope for this draft: finalized cloud or local topology, selected agent framework, product database schema, vendor subscriptions, legal-entity structure for future acquisitions, detailed staffing, and assumptions that unbuilt systems are already running. Those decisions belong in canvases, work orders, and architecture decision records (ADRs) when supported by actual requirements.

2. Architectural drivers and governing constraints

Driver	Architectural consequence
First genuine arm's-length sale with collected revenue > $0 is the only initial commercial pass/fail KPI	Each venture has a payment/attribution path and evidence record; operational metrics remain diagnostics, not substitute success criteria.
Launch quickly at low incremental cost	Reuse existing lab, business facilities, and IP; avoid platform-building ahead of a purchasable offer.
Approximately 70% speculative effort, while preserving near-term acquisition	Prioritize Opportunity Intelligence and the Egypt media POC in parallel with existing-income follow-through.
One factory, many experiments	Common services expose replaceable interfaces; each venture has logical and financial boundaries from inception.
Owner remains involved by choice	Automate repetitive research and operations; reserve meaningful product, creative, relationship, investment, and consequential decisions for Ken.
Commercial complementarity without forced coupling	Share audiences, production, or IP through explicit relationships; allow a venture to survive without another venture's channel or platform.
Lab-first, cloud-ready when justified	Model commercial hosting costs during planning; isolate experimental workloads; design a reproducible migration path.
Optional operate / replicate / license / sell / retire outcomes	Maintain an identifiable inventory of IP, data, code, customers, financial records, contracts, and third-party dependencies.

Design rule: the cost of separation must not overwhelm the cost of experimentation. Logical boundaries are mandatory; duplicate legal entities, cloud accounts, or full technology stacks are not.

3. Context and business boundaries

flowchart TB
    K[Ken: owner and governance] --> PM[Portfolio management]
    PM --> FAC[Shared business factory]
    FAC --> OI[Opportunity Intelligence]
    FAC --> SD[Sales Development]
    FAC --> PROD[Research and production]
    FAC --> ADMIN[Finance and administration support]
    FAC --> ENG[Engineering, AI and deployment]
    OI --> V1[Employment and contract channel]
    OI --> V2[Fractional Insight ecosystem]
    SD --> V2
    PROD --> V3[Withered Sanctum ecosystem]
    ENG --> V4[Future independent ventures]
    ADMIN --> V2
    ADMIN --> V3
    ADMIN --> V4
    V2 -. opt-in commercial adjacency .-> V4
    V3 -. opt-in audience and IP adjacency .-> V4

The diagram shows responsibility and potential dependencies, not deployed software, completed integrations, or a requirement that each box be an agent. Employment and contract acquisition is an income channel, not automatically a separately transferable business. Fractional Insight CIO, LLC is an existing commercial asset; the future legal structure of other ventures is undecided.

3.1 Portfolio management

Portfolio management owns the venture register, priority, authorized effort and incremental cash ceilings, experiment clocks, review dates, commercial evidence, and decisions to continue, redesign, operate, sell, or retire. Ken is the investment and exception authority. AI may prepare briefs and proposed decisions, but cannot silently authorize a new venture or commitment.

3.2 Business units and ecosystems

An ecosystem groups commercially adjacent ventures, but does not erase their boundaries.

• Fractional Insight: existing consulting and Gaussian relationship, new-client acquisition, narrow AI services, and potential software/products arising from demonstrated customer problems.
• Withered Sanctum: Ancient Egypt media POC, Pyramid and related original publishing, and potential future games or interactive products.
• Additional ventures: admitted through a short canvas, explicit priority and authorization; no permanent restriction to the two initial ecosystems.

A YouTube channel, media-production service, Pyramid publishing product, and prospective game may be different assets or ventures even when they share a brand. Define the commercial boundary in the canvas rather than assume one entity owns or transfers everything.

3.3 Shared factory

The factory provides reusable capabilities to ventures through explicit inputs, outputs, access rules, cost attribution, and documented dependencies. Shared services must not become indispensable black boxes that prevent a venture from operating or being sold independently.

4. Logical capability architecture

Capability	Responsibility	Initial status / priority	Boundary
Portfolio governance and evidence	Canvas, venture register, approvals, gates, actual receipts and decisions	P0 minimal records	Portfolio-wide; Ken authorizes
Opportunity Intelligence	Independently discover, deduplicate, qualify, and report employment, contract, and FI opportunities	P0 first shared automation	Internal research and brief; no autonomous applications or outreach
Existing-income follow-through	Applications, proposals, Gaussian and FI follow-up	P0 ongoing human activity	Ken authorizes external actions
Egypt media production	Research, source dossier, script, assets, rendering, metadata and performance observations	P0 venture POC	Ken approves publication and editorial claims
Sales Development	Prospect research, tailored drafts, pipeline and follow-up preparation	P1	No unsolicited sends without approved scope and permissions
Product/AI-service fulfillment	Scope, intake, production, acceptance, delivery	P1, driven by paid offer	Venture-specific deliverable and customer obligations
Finance and administration	Invoice preparation, cost/receipt tagging, obligations, receivables and reporting	Minimal records at P0; fuller service later	Authoritative accounting stays in approved systems; no autonomous money movement
Engineering, AI and deployment	Reusable model access, automation execution, configuration and releases	Build only what active POCs need	Controlled environment and release permissions
Asset and exit management	Rights/dependencies inventory, export and recovery procedures	Minimal inventory at birth; P2 hardening	No assumption that contracts/accounts/data can transfer

A capability can be implemented by existing software, a deterministic workflow, an AI agent, a person, or a combination. Organization chart ≠ agent inventory. Choose the simplest reliable execution form when designing each bounded process.

5. Execution and autonomy model

5.1 Separate decision-making from execution

1. Deterministic software/workflows: use for repeatable rules, scheduling, deduplication where exact, accounting arithmetic, file conversion, rendering, and recording state.
2. AI-assisted steps: use for interpretation-heavy research, qualification, drafting, script development, and proposals. Require source references and explicit uncertainty where material.
3. Human steps: use for portfolio allocations, major product choices, consequential editorial decisions, customer commitments, and other actions requiring authorization.

A production pipeline can mix all three; no mandate to introduce a multi-agent framework or custom interface for the first POC.

5.2 Authority matrix — initial default

Action	Default authority
Research permitted sources and create internal opportunity or topic briefs	May run unattended within approved access, scope, rate, and budget
Draft scripts, outreach, applications, proposals, or invoices	May prepare; not equivalent to sending or committing
Publish a video or product; submit an application; send customer-facing outreach	Ken approval before action unless a narrower explicit future delegation is recorded
Accept contracts, make promises, spend money, issue refunds, change live production, or grant access	Explicit authorized human decision and appropriate system controls
Stop a failed experiment	Ken investment decision; automation may flag deadline and prepare closure checklist

Record authority expansions per workflow: permitted actions, environment, accounts, spending/rate limits, escalation rules, rollback where available, and audit evidence. The system must not report a proposed or drafted action as completed.

5.3 Bounded autonomy progression

ASSISTED → DELEGATED → SUPERVISED → BOUNDED OPERATIONAL AUTONOMY

Advance a specific workflow only after demonstrating adequate quality, repeatability, exception handling, access control, and observability. The aim is to remove required routine labor, not to exclude Ken from enjoyable or valuable work.

6. Minimum venture contract and information architecture

Every activated experiment receives a venture ID and a short canvas. The minimum logical record includes:

Area	Minimum information
Identity	Venture ID, ecosystem, owner, offer/brand, stage and responsible decision-maker
Market	Buyer, problem, current alternative, proposed value, acquisition channel and commercial adjacencies
Validation	Authorized kickoff (D0), build and acquisition assumptions, maximum sale window, next review date, first-sale evidence rule
Budget	Incremental cash ceiling, owner-time allocation, actual spending and labor; shared costs attributed transparently
Commercial	Payment mechanism, transaction reference, payer evidence, collected amount and date, refunds, fees, earned vs. unearned/restricted receipts, obligations
Assets	Repository/content location, domain/brand, original and third-party IP, licenses, data classification, customers, configuration and secrets ownership
Deployment	Environment, dependencies, backup/recovery needs, production-cost estimate, migration economics and safety requirements
Exit	Export, independent-operation dependencies, contract/account/data transfer constraints, customer closure duties and asset disposition

Systems of record: do not duplicate authoritative payments or financial accounts inside an agent's memory. QuickBooks and payment-provider records are existing business assets; specific connector/API availability and accounting integration remain to be verified. The venture evidence log references authoritative transactions and preserves only the data needed for attribution and decisions, never payment credentials. Customer and candidate information is accessible only to workflows with a legitimate purpose.

Suggested evidence flow: source / order → captured reference → verified state → venture attribution → portfolio review. Maintain provenance for sources, generated assets, and claims where relevant. A channel's audience metrics, draft invoice, pledge, or unpaid booking must not be presented as a qualifying collected sale.

7. Integration and modularity rules

1. Explicit interfaces. Record each shared service's inputs, outputs, errors, permissions, and owner. Start with documented file or API contracts; introduce message brokers only if an actual use case requires them.
2. Venture-scoped configuration and data. At minimum use separate identifiers, access boundaries, repositories/content areas or namespaces, secrets, and financial tags. Do not assume every venture needs a separate database or infrastructure account.
3. Replaceable dependencies. A venture should be able to replace shared inference, workflow automation, checkout, or hosting using documented configuration/data export rather than rewriting its product from scratch. Absolute provider independence is not required for a seven-day POC; known lock-in must be recorded.
4. Provenance and rights. Record sources, original work, generated/third-party assets, licenses, attribution/disclosure requirements, and rights retained by the parent or licensed to the venture.
5. No accidental cross-venture data sharing. A shared AI or CRM capability does not grant one venture permission to use another venture's customer records, proprietary materials, or prospect data.
6. Extract after repetition. On the first use, solve the concrete problem with a separable implementation. After a second justified use, consider promoting it to a shared service. This is a heuristic, not a mandatory numeric gate.
7. Shutdown must be possible. Maintain enough dependency and obligation information to stop an experiment without breaking another venture or abandoning customers.

7.1 Asset ownership and possible sale

Keep a venture asset register distinguishing owned assets, shared/factory-owned assets, licensed assets, and third-party accounts or services. A potential buyer must be able to understand what is included and what must be replaced or newly contracted. A sale is never assumed to include the entire Pyramid IP, other channels, central AI platform, or FI customer base by default. Transferability remains subject to actual rights, consent, platform rules, and buyer interest.

8. Deployment architecture and cloud migration economics

8.1 Existing capacity and deployment posture

Available starting assets: home lab with static IP, firewall, reverse proxy and virtualization; public-facing Docker server; Forge / Gateway / Oracle AI triad; local-model capability and Project Thoth engineering work. These are available assets, not evidence that a new portfolio application or agent is deployed.

The intended initial posture is lab-first for suitable experiments. Keep experimental workloads isolated from personal information, existing revenue services, and one another. Use least-privilege accounts, managed secrets, appropriate backups, updates, restore tests commensurate with obligations, and constrained public exposure. Confirm actual capacity and environment boundaries during the relevant implementation work order.

A proposed logical placement—not a verified deployment—is:

• Forge: development and human-directed engineering work.
• Gateway / public Docker capacity: appropriate application, automation, and serving workloads after security/capacity review.
• Oracle: local AI inference, subject to existing resource and access constraints.

These assignments reflect the existing triad's broad roles; concrete hostnames, networks, ports, containers, and access paths are TBD, not defined here. A public service does not automatically belong on a specific machine.

8.2 Cloud affordability floor

Each software venture's canvas will price a fit-for-purpose Azure, DigitalOcean, or alternative production design during planning. Estimate compute, storage, network/egress, backups, managed dependencies, monitoring, support, and per-customer usage as applicable. Quote actual provider pricing when selecting the design; do not assume a generic cloud price.

For a simple subscription model:

Contribution/customer = collected price/customer − variable cost/customer

Break-even active paying customers = ceiling(monthly fixed production costs ÷ contribution/customer)

This calculation requires positive contribution/customer and adjustments for refunds, taxes as applicable, variable usage, payment fees, migration spending and cash reserve. A one-time migration must be fundable separately; for irregular revenue use a conservative dependable-contribution estimate rather than a single exceptional month.

Migration decision = affordability AND operational justification. Affordability sets the economic floor; capacity, availability expectations, security, privacy, recovery, or customer commitments supply the reason to move. If the lab cannot safely fulfill a product's current obligations, narrow/pause the offer or fund an appropriate environment earlier. Early Access is not an exemption from those obligations.

8.3 Portability package (incremental)

For a venture that approaches commercial operation or sale, assemble: reproducible build/deployment instructions; sanitized configuration example; dependency and license inventory; backup/restore and export procedure; domains/accounts inventory; operating runbook; and outstanding customer obligations. Do not build a complete migration platform for unvalidated experiments.

9. Lifecycle and experiment gates

flowchart LR
    P[Propose and authorize] --> B[Build usable offer]
    B --> L[Launch and acquire]
    L --> G{Collected first sale in window?}
    G -->|Yes| R[Review further investment]
    G -->|No; adequately resourced| F[Fail current hypothesis]
    G -->|Resources unavailable| D[Explicitly defer]
    R --> O[Operate / expand / license / offer for sale]
    F --> X[Retire / archive / explicit redesign]
    D --> P
    O --> A[Preserve reusable assets and evidence]
    X --> A

The first sale is the only initial commercial pass/fail KPI. A pass permits an investment decision, not automatic scaling, profitability, or autonomy. The seven-day Egypt publication is an operational milestone and the $10,000 gross collected in the first 30 days is an ambitious stretch outcome, neither a replacement for the first-sale gate. Employment and Gaussian have their different first-paycheck and incremental-revenue rules as specified in PORTFOLIO.md.

Each experiment must have a recorded D0, adequately resourced validation window, intermediate reviews, incremental ceilings, and an exit/fulfillment procedure. Never silently extend an experiment, infer an unverified sale, or label a deferred effort a commercial failure.

10. Initial implementation slices and boundaries

Slice A — Opportunity Intelligence (W1, P0)

Purpose: independently find, deduplicate, qualify, and organize employment, short-term contract, and FI client opportunities, so Ken spends attention on decisions and relationships rather than repetitive discovery.

Minimum flow: approved source → retrieve permitted listings/material → capture source link, date and provenance → deduplicate → compare with approved criteria and career/service source material → produce actionable brief and pipeline record → Ken reviews and selects action.

Initial acceptance: a repeatable discovery cycle produces current, actionable, deduplicated findings that Ken can verify and use. False positives, missed source access, owner time and actual downstream actions are diagnostics. Sending applications or outreach is not implied by research autonomy. Data sources, credentials, matching method, reporting destination, cadence, and actual stack remain TBD for D0.

Slice B — Ancient Egypt media (W2, P0)

Purpose: prove rapid original video production using repeatable tooling and establish a potential audience for Withered Sanctum/Pyramid-related products.

Minimum flow: editorial topic → sourced research dossier and claim list → original script → licensed/original production assets and rights log → narration and repeatable render → factual/rights/quality review → Ken publication approval → publish and preserve URL/artifacts → collect performance and commercial attribution separately.

Initial acceptance: one original publicly published video with verifiable URL, source/rights evidence, reproducible production steps, actual incremental cost and owner hours within the authorized seven-day sprint target. This proves operational launch, not revenue. The first attributable qualifying paid transaction is the separate commercial gate. Channel/account access, topic, creative format, exact rendering and publishing tools, and adjacent product remain TBD for the business canvas.

Slice C — Existing revenue and next opportunities (W3/W4, P0/P1)

Maintain live contract/job/client follow-through; prepare Sales Development by reusing the opportunity pipeline. Gaussian growth is measured against the already-paying baseline, not a first-ever sale. No additional shared CRM, autonomous sales agent, or invoice integration is assumed completed.

Slice D — First narrow AI service or SaaS (W6/W7, P1)

Select an offer and buyer first. Provide a purchasable or pilot-ready product with a valid payment path, fulfillment terms, venture attribution, and cloud cost estimate if software. Do not wait for full autonomous operation, elaborate SaaS scaffolding, or a second media channel to make the first sale.

11. Observability, economics, and portfolio review

Every active experiment reports a compact weekly record:

• Commercial gate: qualifying paid sale (YES / NO / NOT YET DUE), verified payment reference, date, amount, product and venture attribution; separate refunds, fees, pledges/prepayments and outstanding fulfillment.
• Execution diagnostics: authorization/build/launch dates, actual human hours, incremental spend, defects, deliverables, source or publication links, and remaining obligations.
• Decision state: next gate/deadline, approved remaining cash/time, issues requiring Ken, and an explicit CONTINUE / OPERATE / REDESIGN / DEFER / RETIRE (or proposed sale/license) decision.

Operational dashboards, views, agent telemetry and sales analytics are later implementation choices. For the first sprint, a durable Markdown or appropriately controlled structured register with source references is sufficient. The financial source of truth must remain reconcilable with payment and accounting records.

12. Architecture decisions and open questions

The following are not decided by this draft. Record material choices as short ADRs with context, choice, tradeoffs, date, owner, and reversal path.

Decision / question	Needed by	Current status
D0, actual weekly hours, incremental cash limits and owners	Sprint authorization	TBD
Opportunity sources, access method, report destination, eligibility criteria and approved unattended scope	W1 D0	TBD
Egypt channel account/brand, first topic, source standard, rights inventory and production tools	W2 D0	TBD
Venture register/evidence store and authoritative transaction references	W0/D0	Minimal format TBD
Which services are shared versus venture-specific after actual second use	As reuse emerges	Defer design
Workflow orchestrator, LLM/model selection, agent framework, and connectors	Per implementation work order	No portfolio-wide mandate
Cloud provider, actual deployment topology, cost floor and migration reserve	Per software canvas	Estimate before selling; verify before migration
SaaS buyer, product, customer-data classification and offer terms	W7 canvas	Unknown
Intellectual property and legal ownership boundaries for media, Pyramid, and potential asset sales	Before commitments/transfer	Verify and document
Customer-funded development suitability, obligations, refunds and accounting treatment	Per venture canvas	Evaluate; do not assume funding

13. Document map and next actions

• VISION.md: founding thesis and non-negotiable principles.
• PORTFOLIO.md: uncertainty, allocation, priorities, windows, commercial gates and venture register policy.
• PROJECT-PLAN.md: workstreams, first seven days and 90-day roadmap.
• PROJECT-CHARTER.md: proposed, not presumed created; authority and investment limits.
• canvases/EGYPT-MEDIA.md and canvases/OPPORTUNITY-INTELLIGENCE.md: proposed D0 business/process canvases.
• logs/EXPERIMENT-REGISTER.md: proposed record of actual kickoffs, receipts, evidence and decisions.
• ADRs, work orders, runbooks and per-venture repositories: create only when their first real use justifies them.

Next architecture task: approve the minimum venture/evidence record and the two P0 canvas boundaries. Then execute W1 and W2 in parallel while maintaining W3. Record actual technology choices from those builds and revise this draft rather than treating its conceptual boxes as deployed components.

---

Architecture principle: Shared where it creates leverage; separate where it preserves accountability, customer trust, and the freedom to operate, replicate, license, sell, or retire.