SPYRE Capacity Intelligence Platform

Build the operational backbone before scale multiplies the risk.

SPYRE's business depends on matching high-value capacity requirements against fast-changing global inventory. The current workbook holds valuable intelligence, but the process around it relies on manual updates, disconnected opportunity tracking and individual memory. Each new hire and each new client widens that gap.

Problem statement

Data centre capacity information at SPYRE comes in as messy, relationship-sourced updates — an email, a PDF attached to that email, a phone call, a text message, or a spreadsheet — each in the operator's own format and on the operator's own schedule. Today, a person must read every update, remember it or key it into a spreadsheet by hand, and hope every other copy of that spreadsheet gets updated too. This creates four concrete risks for SPYRE:

1. Capacity numbers go stale between manual updates, so the number a salesperson quotes may already be wrong.
2. The same site can be offered to two different customers before anyone notices, because there is no single, protected record of what is already reserved.
3. Knowledge lives with individual people, not with the business — a new team member has no single place to look, only people to ask.
4. Every client proposal means manually copying, checking and redacting data from scattered sources, which takes hours and invites mistakes.

This proposal is built to solve exactly this problem: turn messy, relationship-sourced capacity updates into a single trusted, governed and searchable record — with AI doing the reading and a person always doing the final check — before that record becomes revenue-ready data.

The challenge is fragmented operations, not Excel itself.

The supplied workbook contains seven operating views, including a 48-column master site tab, supplier outreach tracking and client-specific opportunity lists. The future system must work with the way operators actually share information — while removing the coordination risk of doing everything by hand. To make this concrete, this working platform imports the real workbook: 199 source rows produce 156 canonical records, and the one incomplete stray cell is isolated as an error rather than silently guessed.

Operating leverage you can measure, not just describe.

Each value claim below is paired with the metric that will prove it. Baselines are captured during discovery so that improvement is measured against SPYRE's real starting point, not an assumed one.

One connected flow from operator update to placed capacity.

The model is designed around unstructured, relationship-sourced information. Operators keep sharing updates the way they do today; SPYRE gains control at the point of intake.

An operational product, not a visual mock-up.

The scope below maps directly to the functional requirements in SPYRE's Scope & Requirements document (FR-1 to FR-6). The working platform accompanying this proposal already implements the core flow using the shared workbook.

Phase 1 boundaries

Two internal views with clear permission boundaries.

Cloud-neutral services around a protected data layer.

This working platform runs on Docker Compose. Production uses the same containers on a managed cloud platform, adding managed PostgreSQL, object storage, an identity provider, monitoring and automated backups.

Technology selection

Grounded answers and confirmed actions, not a chatbot bolted on.

Two AI capabilities work together in this platform. TEDRA — ThirdEye Data AI Assistant — works inside both Manager and Sales views: it inherits the signed-in user's permissions, cites the operational evidence behind every answer, declines what it cannot support, and asks for explicit confirmation before changing data or creating an output. This delivers the AI-assisted query capability in FR-4.3. AI Intake is the second capability: it reads one operator document at a time — a PDF, an email, call notes or a chat transcript — and proposes each field with a confidence score and the exact source text, so a person only has to check and confirm, not retype everything by hand. This delivers the AI-assisted extraction capability in FR-1.

Role and action matrix

Extraction quality controls

A SPYRE-owned platform, with Salesforce as a connected channel.

Why Option A

Sixteen weeks to production, gated by evidence.

A planning proposal, not a committed schedule — it is confirmed after discovery, source-system access, security review and agreement of acceptance baselines. Each gate below must pass before the next stage proceeds.

Phase gates

Delivery team

• Project Manager — plan, risks, governance and acceptance tracking
• Business Analyst / Product Owner — requirements, field dictionary, UAT scenarios
• Solution Architect — technical design, security and integrations
• Data Engineer — migration, ingestion, quality rules and reconciliation
• AI Engineer — extraction and query services, evaluation, review controls
• Backend Engineers — APIs, workflow, concurrency and audit services
• Frontend Engineer / UX — responsive, role-based user experience
• QA Engineer — functional, regression, performance and security testing
• DevOps / Security Engineer — CI/CD, environments, monitoring and production readiness

Governance and acceptance

Acceptance is based on observable behaviour: imports reconcile to source with visible warnings; role restrictions and approval rules hold under test; conflicting reservations are blocked; redacted outputs contain only the selected sites with their snapshot retained; and named UAT users complete the agreed scenarios without engineering help. Performance and availability targets are set after production volumes are confirmed in discovery, and no critical or high security issue remains open at go-live.

Defence in depth for commercially sensitive data.

Deployment profiles

Extend only after Phase 1 proves the model.

Phase 1, 2 and 3 at a glance

All three phases build on the same platform — nothing here is a separate project. Phase 1 is the committed 16-week plan described in Section 10. Phases 2 and 3 are the future vision for this same platform, planned but not yet started, and their timing depends on Phase 1 going live first.

The Phase 2 and 3 timings above are directional planning assumptions, counted from the end of Phase 1 — not commitments. SPYRE's own scope notes that Phases 2 and 3 may change based on Phase 1 outcomes.

Key risks and mitigations

Assumptions and dependencies

• SPYRE owns inventory definitions, field rules, source files and acceptance decisions.
• Operators continue sharing data in manual and semi-structured formats.
• The master workbook remains authoritative until migration and UAT sign-off.
• Named subject-matter users are available for weekly decisions and UAT.
• Hosting, region, SSO, retention and compliance requirements are confirmed in discovery.
• The Salesforce object architecture remains stable before Phase 3 mapping begins.
• The CLM system and integration method are confirmed before Phase 2 is baselined.
• Sensitive and personal data is handled under the signed NDA and agreed access policy.

Price the confirmed work breakdown, not an assumed number.

No budget, rates or hosting tier was supplied, so this proposal does not invent a commercial commitment. After the discovery workshop, ThirdEye Data will issue a scope-linked estimate covering one-time implementation, recurring infrastructure and licence costs, support, payment milestones and optional Phase 2–3 items — each component tied to the phase gates above (discovery to Gate 1, implementation to Gates 2–3, deployment to Gates 4–5, followed by a proposed four-week hypercare and agreed support tier).