syntaxmatrix 2.6.4.4__py3-none-any.whl → 3.0.0__py3-none-any.whl
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- syntaxmatrix/__init__.py +6 -4
- syntaxmatrix/agentic/agents.py +195 -15
- syntaxmatrix/agentic/agents_orchestrer.py +16 -10
- syntaxmatrix/client_docs.py +237 -0
- syntaxmatrix/commentary.py +96 -25
- syntaxmatrix/core.py +142 -56
- syntaxmatrix/dataset_preprocessing.py +2 -2
- syntaxmatrix/db.py +0 -17
- syntaxmatrix/kernel_manager.py +174 -150
- syntaxmatrix/page_builder_generation.py +654 -50
- syntaxmatrix/page_layout_contract.py +25 -3
- syntaxmatrix/page_patch_publish.py +368 -15
- syntaxmatrix/plugins/__init__.py +0 -0
- syntaxmatrix/premium/__init__.py +10 -2
- syntaxmatrix/premium/catalogue/__init__.py +121 -0
- syntaxmatrix/premium/gate.py +15 -3
- syntaxmatrix/premium/state.py +507 -0
- syntaxmatrix/premium/verify.py +222 -0
- syntaxmatrix/profiles.py +1 -1
- syntaxmatrix/routes.py +9782 -8004
- syntaxmatrix/settings/model_map.py +50 -65
- syntaxmatrix/settings/prompts.py +1435 -380
- syntaxmatrix/settings/string_navbar.py +4 -4
- syntaxmatrix/static/icons/bot_icon.png +0 -0
- syntaxmatrix/static/icons/bot_icon2.png +0 -0
- syntaxmatrix/templates/admin_billing.html +408 -0
- syntaxmatrix/templates/admin_branding.html +65 -2
- syntaxmatrix/templates/admin_features.html +54 -0
- syntaxmatrix/templates/dashboard.html +285 -8
- syntaxmatrix/templates/edit_page.html +199 -18
- syntaxmatrix/themes.py +17 -17
- syntaxmatrix/workspace_db.py +0 -23
- syntaxmatrix-3.0.0.dist-info/METADATA +219 -0
- {syntaxmatrix-2.6.4.4.dist-info → syntaxmatrix-3.0.0.dist-info}/RECORD +38 -33
- {syntaxmatrix-2.6.4.4.dist-info → syntaxmatrix-3.0.0.dist-info}/WHEEL +1 -1
- syntaxmatrix/settings/default.yaml +0 -13
- syntaxmatrix-2.6.4.4.dist-info/METADATA +0 -539
- syntaxmatrix-2.6.4.4.dist-info/licenses/LICENSE.txt +0 -21
- /syntaxmatrix/{plugin_manager.py → plugins/plugin_manager.py} +0 -0
- /syntaxmatrix/static/icons/{logo3.png → logo2.png} +0 -0
- {syntaxmatrix-2.6.4.4.dist-info → syntaxmatrix-3.0.0.dist-info}/top_level.txt +0 -0
syntaxmatrix/settings/prompts.py
CHANGED
|
@@ -7,6 +7,10 @@ SMXAI_CHAT_IDENTITY = f"""
|
|
|
7
7
|
"""
|
|
8
8
|
|
|
9
9
|
SMXAI_CHAT_INSTRUCTIONS = """
|
|
10
|
+
You respond to queries that are about your company only.
|
|
11
|
+
If a query is not about your company, kindly bring the conversation to be about your company.
|
|
12
|
+
Be professional at all times
|
|
13
|
+
|
|
10
14
|
Content & Formatting Blueprint (Adhere Strictly):
|
|
11
15
|
Structure your response using the following elements as appropriate for the topic. Prioritize clarity and information density. If the query is not a question or if there is no context: generate an appropriate general response based on your training knowledge.
|
|
12
16
|
else if the query is a question:
|
|
@@ -25,12 +29,13 @@ SMXAI_CHAT_INSTRUCTIONS = """
|
|
|
25
29
|
1. Decide which of the following layouts best fits the content:
|
|
26
30
|
• Comparison across attributes or (Key:Value) pairs → HTML <table>.
|
|
27
31
|
• When creating a table, adhere to the following styling instructions:
|
|
28
|
-
a.
|
|
32
|
+
a. Firstly, define any 3 colors and assign them to c1,c2,c3 (example: c1="#EDFBFF", c2="#CCCCCC", c3="#E3E3E3". c2 and c3 should be similar but slightly different shades.
|
|
33
|
+
|
|
29
34
|
b. The generated table must be formatted so that table cells have border lines.
|
|
30
35
|
c. The table head (<thead>) must always have a background color of c1.
|
|
31
36
|
d. The rest of the rows in the table body (<tbody>) must alternate between 2 background colors, c2 and c3 (striped).
|
|
32
|
-
• Use bullet points for simple lists of items, features → HTML
|
|
33
|
-
• Use ordered
|
|
37
|
+
• Use bullet points <ul> for simple lists of items, features → HTML.
|
|
38
|
+
• Use ordered list <ol> for sequences or ranking or steps in a process → HTML
|
|
34
39
|
2. Keep cells/list items concise (one fact or metric each).
|
|
35
40
|
3. All markup must be raw HTML. Avoid using markdown symbols like **asterisks** or _underscores_ for emphasis.
|
|
36
41
|
4. Do not wrap the answer inside triple back-ticks.
|
|
@@ -39,387 +44,1403 @@ SMXAI_CHAT_INSTRUCTIONS = """
|
|
|
39
44
|
8. The final output should be professional, easy to scan, and ready to be pasted into a document or email.
|
|
40
45
|
"""
|
|
41
46
|
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
47
|
+
SMXAI_WEBSITE_DESCRIPTION = """
|
|
48
|
+
SyntaxMatrix — Website Description
|
|
49
|
+
|
|
50
|
+
SyntaxMatrix is an enterprise-first AI engineering company that builds governed, client-owned AI platforms for organisations that need control over their data, their deployment boundary, and their operational outcomes. The company’s flagship product, SyntaxMatrix Platform Provisioner (smxPP), is a full-stack Python platform provisioner designed to deliver complete AI-enabled applications into a client’s environment in a repeatable, auditable, and maintainable way.
|
|
51
|
+
|
|
52
|
+
Most organisations do not struggle to “try AI”. They struggle to keep it working reliably after the initial proof-of-concept. The real challenge starts when prototypes become production workloads: knowledge sources grow, policies tighten, teams change, and the solution needs governance, monitoring, access control, and repeatability. SyntaxMatrix exists to solve that “Day 2” reality by providing a platform that can be deployed and operated as part of an organisation’s actual systems landscape, rather than as a fragile demo.
|
|
53
|
+
|
|
54
|
+
smxPP is not a hosted wrapper around AI APIs. It is a provisioned platform: a deployable system that is installed into a client’s own instance, where the client retains sovereignty over their runtime, their documents, their users, and the security perimeter. The result is a governed AI platform that can be run in regulated environments, private networks, or controlled cloud deployments — with clear role separation, traceability, and a data pipeline that is designed for operational integrity.
|
|
55
|
+
|
|
56
|
+
What smxPP provides
|
|
57
|
+
|
|
58
|
+
smxPP provisions a complete platform surface, not a single feature. The platform is built around real enterprise needs: controlled user access, secure content ingestion, governed retrieval pipelines, internal documentation and pages, structured workflows, and optional machine learning tooling for teams that need it. The platform is engineered so organisations can standardise how they deploy and operate AI functionality across departments, business units, and client projects.
|
|
59
|
+
|
|
60
|
+
1) Role-aware access and controlled operations
|
|
61
|
+
|
|
62
|
+
smxPP includes role-aware access control so that administration, staff actions, and end-user experiences remain separated and auditable. This matters in real deployments: a platform that can ingest and answer from internal knowledge must enforce who can upload, who can publish, who can configure, and who can export. smxPP is built so that organisations can run AI-enabled capabilities without turning governance into an afterthought.
|
|
63
|
+
|
|
64
|
+
2) Document ingestion, retrieval, and RAG that can be governed
|
|
65
|
+
|
|
66
|
+
The platform supports document ingestion and retrieval workflows designed for enterprise usage: structured chunking, indexing, retrieval, and controlled answering. smxPP enables Retrieval-Augmented Generation (RAG) experiences where an assistant can answer questions grounded in organisational content, while still giving operators the tooling to manage sources, auditing, and quality. The emphasis is on reliability and clarity: content is ingested with intent, stored with traceability, and retrieved in a way that can be improved over time.
|
|
67
|
+
|
|
68
|
+
3) Page Studio for internal portals and knowledge-driven pages
|
|
69
|
+
|
|
70
|
+
smxPP includes a page system that enables organisations to generate and manage internal or external pages from structured content, with an admin surface for editing, publishing, and maintaining these pages as part of a broader platform. This is critical when AI must integrate into real organisational communication: policies, procedures, services, knowledge bases, onboarding documentation, and operational content are not separate from AI — they are part of the same system.
|
|
71
|
+
|
|
72
|
+
4) Documentation and knowledge base experience inside the platform
|
|
73
|
+
|
|
74
|
+
smxPP supports an integrated documentation viewing experience so product documentation and operational knowledge can live alongside the system itself. For enterprise teams, this reduces friction: the platform is not just a runtime, but also a controlled surface for guidance, onboarding, and internal enablement.
|
|
75
|
+
|
|
76
|
+
5) Optional ML Lab capabilities for structured analysis and export
|
|
77
|
+
|
|
78
|
+
Where required, smxPP can provide a controlled ML workflow surface: dataset upload, exploration, modelling support, and export of results. This is not positioned as “auto-ML hype”, but as an operational capability that helps teams validate hypotheses, produce repeatable artefacts, and share outputs in a controlled way.
|
|
79
|
+
|
|
80
|
+
6) Premium features and entitlements that map to operational value
|
|
81
|
+
|
|
82
|
+
smxPP supports premium and enterprise entitlements that correspond to real operational needs: increased usage caps, larger document volumes, scaled user access, expanded storage allowances, and enhanced governance features. The premium model is not a cosmetic upsell — it is tied to the parts of platform operation that genuinely cost time, compute, and support to deliver at enterprise quality.
|
|
83
|
+
|
|
84
|
+
Deployment model: client-owned by design
|
|
85
|
+
|
|
86
|
+
A core differentiator of smxPP is the client-owned instance model. SyntaxMatrix does not host customer instances as a default operating model. Instead, each organisation deploys smxPP into its own environment and controls its own data boundary. This matters for enterprises that cannot accept third-party hosting for compliance, security, or policy reasons. It also matters for organisations that want long-term autonomy: the platform is provisioned so clients can maintain it as part of their internal systems landscape, while still benefiting from a clear upgrade path and supported premium capabilities.
|
|
87
|
+
|
|
88
|
+
smxPP can be deployed in multiple patterns depending on organisational constraints:
|
|
89
|
+
|
|
90
|
+
private cloud deployment (controlled networking and identity)
|
|
91
|
+
|
|
92
|
+
secure cloud environments with strict access controls
|
|
93
|
+
|
|
94
|
+
controlled hosting scenarios where the client remains the operator
|
|
95
|
+
|
|
96
|
+
environments where outbound access is limited and governance is strict
|
|
97
|
+
|
|
98
|
+
This deployment stance is a practical trust signal: it aligns with how security and procurement teams assess operational risk. Instead of asking an organisation to trust a black-box hosted system, smxPP provides a platform they can inspect, configure, and run under their own governance policies.
|
|
99
|
+
|
|
100
|
+
Licensing that supports enterprise trust
|
|
101
|
+
|
|
102
|
+
To support premium entitlements while maintaining operational integrity, SyntaxMatrix provides a dedicated licensing service that integrates with subscription billing and licence enforcement. This licensing architecture is designed to protect both the customer and SyntaxMatrix:
|
|
103
|
+
|
|
104
|
+
Customers get a clear, auditable entitlement model that maps to features and usage caps.
|
|
105
|
+
|
|
106
|
+
SyntaxMatrix ensures subscription state and premium access remain consistent and fraud-resistant.
|
|
107
|
+
|
|
108
|
+
The system can represent real billing conditions (active, past due, grace period, revoked) rather than pretending billing is always perfect.
|
|
109
|
+
|
|
110
|
+
The licensing service integrates subscription management with a controlled entitlement workflow. Premium access is activated via signed licence payloads and is validated through the licensing flow to prevent tampering and unauthorised upgrades. For enterprise buyers, this is not about “locking people out”; it is about ensuring contractual terms and platform governance remain aligned with operational access, and that the platform behaves predictably when billing state changes.
|
|
111
|
+
|
|
112
|
+
Self-serve billing management is supported via the customer portal provided by Stripe, enabling customers to:
|
|
113
|
+
|
|
114
|
+
update payment method
|
|
115
|
+
|
|
116
|
+
view invoices
|
|
117
|
+
|
|
118
|
+
cancel subscription (at period end)
|
|
119
|
+
|
|
120
|
+
manage billing details without support tickets
|
|
121
|
+
|
|
122
|
+
Where payment events require operational nuance, the system supports a grace period model so organisations do not lose access instantly due to a transient billing failure. That is a practical enterprise requirement: it reduces disruption while still enforcing contract reality if issues are not resolved in time.
|
|
123
|
+
|
|
124
|
+
What SyntaxMatrix delivers as a company
|
|
125
|
+
|
|
126
|
+
SyntaxMatrix provides more than software. The company provides platform provisioning services and engineering support tailored to organisations that want durable AI systems rather than disposable demos. Typical engagements include:
|
|
127
|
+
|
|
128
|
+
Platform provisioning and deployment planning
|
|
129
|
+
Helping teams choose the right deployment approach, configure their instance correctly, and align platform operation with security and governance constraints.
|
|
130
|
+
|
|
131
|
+
Knowledge architecture and RAG readiness
|
|
132
|
+
Assisting organisations in structuring content for retrieval, defining ingestion practices, improving chunking strategies, and building a dependable knowledge pipeline.
|
|
133
|
+
|
|
134
|
+
Governance-first configuration and access modelling
|
|
135
|
+
Supporting role design, operational permissions, and audit-ready patterns for how the platform is managed internally.
|
|
136
|
+
|
|
137
|
+
Premium enablement and operational scaling
|
|
138
|
+
Enabling higher-volume usage, larger content stores, and scaling features that align with real enterprise requirements.
|
|
139
|
+
|
|
140
|
+
Optional fine-tuning and privacy-aligned model strategy (where required)
|
|
141
|
+
When organisations require tighter privacy controls or specialised performance, SyntaxMatrix can support model strategy work that aligns with deployment constraints and internal data governance policies.
|
|
142
|
+
|
|
143
|
+
Who smxPP is built for
|
|
144
|
+
|
|
145
|
+
smxPP is designed for organisations and teams that need clarity, governance, and operational reliability:
|
|
146
|
+
|
|
147
|
+
CTOs and engineering leaders who want repeatable platform deployment across teams
|
|
148
|
+
|
|
149
|
+
AI architects who need control of data flows, retrieval behaviour, and access boundaries
|
|
150
|
+
|
|
151
|
+
Compliance-minded organisations that cannot accept casual handling of internal documents
|
|
152
|
+
|
|
153
|
+
Enterprise teams that want self-hosting and BYOK operation rather than vendor lock-in
|
|
154
|
+
|
|
155
|
+
Operators who need auditability, predictable behaviour, and controlled upgrades
|
|
156
|
+
|
|
157
|
+
What makes smxPP different
|
|
158
|
+
|
|
159
|
+
smxPP is differentiated by its stance and its engineering priorities:
|
|
160
|
+
|
|
161
|
+
Client-owned instance model
|
|
162
|
+
The platform is provisioned into a client environment, supporting data sovereignty and deployment control.
|
|
163
|
+
|
|
164
|
+
Governance and operational structure baked in
|
|
165
|
+
Role separation, administrative workflows, and controlled operations are first-class design concerns.
|
|
166
|
+
|
|
167
|
+
A complete platform surface, not a single chatbot
|
|
168
|
+
smxPP includes the tooling required to run AI as a real system: content ingestion, page management, documentation, analytics surfaces, and premium gating.
|
|
169
|
+
|
|
170
|
+
Licensing tied to integrity and trust
|
|
171
|
+
The licensing design is built to ensure subscription status, premium entitlements, and platform behaviour remain aligned and auditable.
|
|
172
|
+
|
|
173
|
+
Designed to deploy and operate, not just to demo
|
|
174
|
+
smxPP is built for “keep it running” realities: changes, growth, governance, and operational continuity.
|
|
175
|
+
|
|
176
|
+
Technical deployment compatibility
|
|
177
|
+
|
|
178
|
+
smxPP is designed to be deployable in modern cloud-native patterns. Many organisations run it using managed deployment environments such as Google Cloud Platform services including Google Cloud Run, while retaining full control of environment variables, secrets management, storage persistence, and network boundary configuration. The architecture supports practical operational patterns such as persistent storage backing, instance configuration at deploy time, and clear separation between platform runtime and customer-owned content.
|
|
179
|
+
|
|
180
|
+
Where organisations use domains purchased through registrars such as Namecheap, smxPP’s deployment model supports domain mapping and DNS configuration as part of a repeatable, documented rollout process.
|
|
181
|
+
|
|
182
|
+
Closing positioning
|
|
183
|
+
|
|
184
|
+
SyntaxMatrix builds for organisations that are serious about AI as an operational capability — not as a marketing demo. smxPP is engineered to provision governed, client-owned AI platforms that integrate into real environments with access control, auditable configuration, and a licensing model that supports both enterprise trust and commercial sustainability.
|
|
185
|
+
|
|
186
|
+
If an organisation wants AI capabilities that can be deployed securely, operated reliably, and scaled with confidence — while keeping ownership of data and deployment — SyntaxMatrix and smxPP provide the platform and the engineering discipline to make that practical.
|
|
95
187
|
"""
|
|
96
188
|
|
|
97
|
-
|
|
98
|
-
|
|
189
|
+
|
|
190
|
+
SMXAI_HOME_PAGE_INSTRUCTIONS = f"""
|
|
191
|
+
> IMPORTANT CONTEXT FOR THE GENERATOR
|
|
192
|
+
|
|
193
|
+
- SyntaxMatrix is the company.
|
|
194
|
+
- SyntaxMatrix Platform Provisioner (smxPP) is the product.
|
|
195
|
+
- This is an enterprise homepage: it must build trust, communicate substance, and explain operational reality.
|
|
196
|
+
- This page must NOT read like a startup landing page or a hype brochure.
|
|
197
|
+
|
|
198
|
+
---
|
|
199
|
+
|
|
200
|
+
## PLAN GENERATION CONTRACT (MANDATORY)
|
|
201
|
+
|
|
202
|
+
When generating the page plan JSON:
|
|
203
|
+
|
|
204
|
+
- EVERY major section MUST include:
|
|
205
|
+
- needsImage: true
|
|
206
|
+
- imgQuery: "<specific, concrete image search query>"
|
|
207
|
+
- Images MUST be attached at section level.
|
|
208
|
+
- Do NOT rely on templates to infer images.
|
|
209
|
+
- If a section lacks needsImage + imgQuery, the plan is INVALID.
|
|
210
|
+
|
|
211
|
+
This applies to:
|
|
212
|
+
- hero
|
|
213
|
+
- problem framing
|
|
214
|
+
- solution overview
|
|
215
|
+
- platform highlights
|
|
216
|
+
- deployment models
|
|
217
|
+
- trust / governance
|
|
218
|
+
- licensing model
|
|
219
|
+
- plans overview
|
|
220
|
+
- proof / credibility
|
|
221
|
+
- final CTA
|
|
222
|
+
|
|
223
|
+
---
|
|
224
|
+
|
|
225
|
+
## GLOBAL CONTENT RULES (NON-NEGOTIABLE)
|
|
226
|
+
|
|
227
|
+
- Each MAJOR section must include 2–3 full paragraphs minimum.
|
|
228
|
+
- Each paragraph must be 4–6 complete sentences.
|
|
229
|
+
- Prose explanations MUST come before cards or bullets.
|
|
230
|
+
- Cards and bullets may ONLY summarise AFTER prose.
|
|
231
|
+
- Avoid slogans without explanation.
|
|
232
|
+
- Assume the reader is technical and sceptical.
|
|
233
|
+
|
|
234
|
+
Thin or overly short content is invalid.
|
|
235
|
+
|
|
236
|
+
---
|
|
237
|
+
|
|
238
|
+
## GLOBAL IMAGE RULES (NON-NEGOTIABLE)
|
|
239
|
+
|
|
240
|
+
- Each major section must include exactly ONE image.
|
|
241
|
+
- Prefer: architecture diagrams, platform UI visuals, system diagrams, abstract technical visuals.
|
|
242
|
+
- Avoid: lifestyle photos, generic startup imagery, people (unless explicitly requested).
|
|
243
|
+
- Do not reuse the same imgQuery across sections.
|
|
244
|
+
|
|
245
|
+
---
|
|
246
|
+
|
|
247
|
+
## A) LAYOUT & HERO VISUAL RULES
|
|
248
|
+
|
|
249
|
+
### Hero Alignment Options (EXPLICIT)
|
|
250
|
+
Support both and select one:
|
|
251
|
+
|
|
252
|
+
- Default: heroAlignment = "left"
|
|
253
|
+
- Alternative: heroAlignment = "center"
|
|
254
|
+
|
|
255
|
+
The chosen alignment MUST be emitted in the plan.
|
|
256
|
+
|
|
257
|
+
### Hero Overlay Rules (MANDATORY)
|
|
258
|
+
- Hero text overlay MUST be glassy/translucent.
|
|
259
|
+
- The hero MUST NOT use an opaque white banner/card that blocks the image.
|
|
260
|
+
- Overlay opacity must allow the hero image to remain clearly visible.
|
|
261
|
+
|
|
262
|
+
---
|
|
263
|
+
|
|
264
|
+
## B) REQUIRED HOMEPAGE STRUCTURE (IN ORDER)
|
|
265
|
+
|
|
266
|
+
### B.1 HERO — Company + Product Positioning
|
|
267
|
+
|
|
268
|
+
Content requirements:
|
|
269
|
+
- 2–3 paragraphs explaining:
|
|
270
|
+
- what SyntaxMatrix is (AI infrastructure + algorithm design company)
|
|
271
|
+
- what smxPP is (deployable platform provisioner)
|
|
272
|
+
- why client-owned deployment matters (data sovereignty, governance, control)
|
|
273
|
+
- Avoid hype. Use concrete, operational language.
|
|
274
|
+
|
|
275
|
+
Hero Headline (choose one strong, enterprise option):
|
|
276
|
+
- "Provision Client-Owned AI Platforms — Securely, Governably, Repeatably"
|
|
277
|
+
OR
|
|
278
|
+
- "Enterprise AI Platforms You Can Own, Deploy, and Govern"
|
|
279
|
+
|
|
280
|
+
Subheadline:
|
|
281
|
+
- Must mention smxPP explicitly and clarify it provisions a complete platform, not a single chatbot.
|
|
282
|
+
|
|
283
|
+
CTAs:
|
|
284
|
+
- Primary: "Explore Services"
|
|
285
|
+
- Secondary: "Read Documentation"
|
|
286
|
+
Optional tertiary link: "Licensing Explained"
|
|
287
|
+
|
|
288
|
+
Visual:
|
|
289
|
+
- needsImage: true
|
|
290
|
+
- imgQuery: "enterprise AI platform hero architecture abstract dark glassmorphism"
|
|
291
|
+
|
|
292
|
+
---
|
|
293
|
+
|
|
294
|
+
### B.2 THE PROBLEM — Why AI Prototypes Fail in Production
|
|
295
|
+
|
|
296
|
+
Content requirements:
|
|
297
|
+
- 2–3 paragraphs explaining the real pain points:
|
|
298
|
+
- teams rebuilding AI infrastructure repeatedly
|
|
299
|
+
- fragile RAG pipelines and unreproducible behaviour
|
|
300
|
+
- lack of governance, audit trails, and role separation
|
|
301
|
+
- mismatch between content systems and AI systems
|
|
302
|
+
- vendor lock-in and unclear data boundaries
|
|
303
|
+
- Follow with a short bullet list summarising 5–7 issues.
|
|
304
|
+
|
|
305
|
+
Visual:
|
|
306
|
+
- needsImage: true
|
|
307
|
+
- imgQuery: "enterprise AI production challenges diagram fragmentation governance"
|
|
308
|
+
|
|
309
|
+
---
|
|
310
|
+
|
|
311
|
+
### B.3 THE SOLUTION — What smxPP Provisions
|
|
312
|
+
|
|
313
|
+
Content requirements:
|
|
314
|
+
- 2–3 paragraphs explaining:
|
|
315
|
+
- smxPP provisions a complete platform surface (not a toy UI)
|
|
316
|
+
- how modules fit together (admin panel, ingestion, assistant, pages, ML tooling, analytics)
|
|
317
|
+
- how this reduces time-to-deploy and increases operational stability
|
|
318
|
+
|
|
319
|
+
Include a short summary list after prose:
|
|
320
|
+
- Role-aware Admin Panel
|
|
321
|
+
- Knowledge ingestion + RAG assistant
|
|
322
|
+
- Page Studio and documentation surfaces
|
|
323
|
+
- ML Lab outputs and exports (where enabled)
|
|
324
|
+
- Licensing boundaries and entitlements (premium)
|
|
325
|
+
|
|
326
|
+
Visual:
|
|
327
|
+
- needsImage: true
|
|
328
|
+
- imgQuery: "AI platform overview diagram admin panel RAG page studio ML lab"
|
|
329
|
+
|
|
330
|
+
---
|
|
331
|
+
|
|
332
|
+
### B.4 PLATFORM HIGHLIGHTS — What Enterprises Actually Get
|
|
333
|
+
|
|
334
|
+
Content requirements:
|
|
335
|
+
- 2 paragraphs introducing the philosophy: operational value > demos.
|
|
336
|
+
- Then provide 6 highlight blocks (each with a 4–6 sentence paragraph, not one-liners):
|
|
337
|
+
1) Role-aware access and governance
|
|
338
|
+
2) Document ingestion and retrieval architecture
|
|
339
|
+
3) RAG assistant with controlled grounding
|
|
340
|
+
4) Page Studio for internal/external portals
|
|
341
|
+
5) Documentation viewer integrated into the platform
|
|
342
|
+
6) Optional ML Lab workflows and exports
|
|
343
|
+
|
|
344
|
+
Cards may summarise each after the prose paragraphs.
|
|
345
|
+
|
|
346
|
+
Visual:
|
|
347
|
+
- needsImage: true
|
|
348
|
+
- imgQuery: "enterprise software dashboard UI panels RAG admin governance"
|
|
349
|
+
|
|
350
|
+
---
|
|
351
|
+
|
|
352
|
+
### B.5 DEPLOYMENT MODELS — Client-Owned by Design
|
|
353
|
+
|
|
354
|
+
Content requirements:
|
|
355
|
+
- 2–3 paragraphs explaining:
|
|
356
|
+
- self-hosted deployment model (client instance)
|
|
357
|
+
- why SyntaxMatrix does not host client instances by default
|
|
358
|
+
- how BYOK and data locality reduce procurement friction
|
|
359
|
+
- Include a comparison block after prose:
|
|
360
|
+
- On-premise
|
|
361
|
+
- Private cloud
|
|
362
|
+
- Controlled cloud deployments (e.g., container-based)
|
|
363
|
+
|
|
364
|
+
Visual:
|
|
365
|
+
- needsImage: true
|
|
366
|
+
- imgQuery: "deployment models on premise private cloud architecture diagram"
|
|
367
|
+
|
|
368
|
+
---
|
|
369
|
+
|
|
370
|
+
### B.6 TRUST & GOVERNANCE — Built for Sceptical Environments
|
|
371
|
+
|
|
372
|
+
Content requirements:
|
|
373
|
+
- 2–3 paragraphs addressing:
|
|
374
|
+
- auditability, role separation, operational controls
|
|
375
|
+
- how content ingestion is managed and traceable
|
|
376
|
+
- how organisations can govern AI behaviour over time
|
|
377
|
+
- Include a short list of enterprise trust signals:
|
|
378
|
+
- controlled permissions
|
|
379
|
+
- clear data boundary
|
|
380
|
+
- reproducible upgrades
|
|
381
|
+
- documented operations
|
|
382
|
+
|
|
383
|
+
Visual:
|
|
384
|
+
- needsImage: true
|
|
385
|
+
- imgQuery: "enterprise compliance security audit governance diagram"
|
|
386
|
+
|
|
387
|
+
---
|
|
388
|
+
|
|
389
|
+
### B.7 LICENSING MODEL — Sustainable, Enforceable, Enterprise-Friendly
|
|
390
|
+
|
|
391
|
+
Content requirements:
|
|
392
|
+
- 2–3 paragraphs explaining:
|
|
393
|
+
- open-core commercial model
|
|
394
|
+
- signed, instance-bound licences
|
|
395
|
+
- remote validation where enabled for subscription integrity
|
|
396
|
+
- grace period handling to avoid sudden disruption
|
|
397
|
+
- Explain the self-serve portal benefits:
|
|
398
|
+
- update payment method
|
|
399
|
+
- view invoices
|
|
400
|
+
- cancel at period end
|
|
401
|
+
- Emphasise fraud resistance as investor-grade assurance, without sounding adversarial.
|
|
402
|
+
|
|
403
|
+
Visual:
|
|
404
|
+
- needsImage: true
|
|
405
|
+
- imgQuery: "software licensing cryptographic signature keys enterprise diagram"
|
|
406
|
+
|
|
407
|
+
---
|
|
408
|
+
|
|
409
|
+
### B.8 PLANS OVERVIEW — Capability Progression (No Prices)
|
|
410
|
+
|
|
411
|
+
Content requirements:
|
|
412
|
+
- 2–3 paragraphs explaining plan philosophy:
|
|
413
|
+
- Trial is full access for evaluation
|
|
414
|
+
- Free is constrained but functional
|
|
415
|
+
- Pro is for small teams adopting smxPP seriously
|
|
416
|
+
- Business is for scaled operations needing more caps and governance
|
|
417
|
+
- Enterprise is for institutions with strict requirements and deeper controls
|
|
418
|
+
- Do NOT include pricing. Explain operational value and typical fit.
|
|
419
|
+
- Provide a concise summary table AFTER prose (caps/features high-level only).
|
|
420
|
+
|
|
421
|
+
Visual:
|
|
422
|
+
- needsImage: true
|
|
423
|
+
- imgQuery: "enterprise pricing tiers progression comparison chart abstract"
|
|
424
|
+
|
|
425
|
+
---
|
|
426
|
+
|
|
427
|
+
### B.9 PROOF & CREDIBILITY — Why This Is Real
|
|
428
|
+
|
|
429
|
+
Content requirements:
|
|
430
|
+
- 2–3 paragraphs explaining:
|
|
431
|
+
- engineering-first platform design
|
|
432
|
+
- documented deployment approach
|
|
433
|
+
- measurable operational focus (reliability, governance, reproducibility)
|
|
434
|
+
- Include a short credibility block:
|
|
435
|
+
- Founder profile line (Bobga Nti — Founder / AI Engineer; MSc AI, platform engineering focus)
|
|
436
|
+
- Company governance line (Yvonne Motuba — Company Secretary; corporate oversight)
|
|
437
|
+
- Keep it professional and factual.
|
|
438
|
+
|
|
439
|
+
Visual:
|
|
440
|
+
- needsImage: true
|
|
441
|
+
- imgQuery: "enterprise software engineering credibility diagram architecture blueprint"
|
|
442
|
+
|
|
443
|
+
---
|
|
444
|
+
|
|
445
|
+
### B.10 FINAL CTA — Next Steps
|
|
446
|
+
|
|
447
|
+
Content requirements:
|
|
448
|
+
- 1–2 paragraphs reinforcing:
|
|
449
|
+
- client-owned AI platform value
|
|
450
|
+
- governance-first stance
|
|
451
|
+
- how to engage (services + documentation + licensing trust)
|
|
452
|
+
|
|
453
|
+
CTAs:
|
|
454
|
+
- "Talk to SyntaxMatrix"
|
|
455
|
+
- "Explore Services"
|
|
456
|
+
- "Read Documentation"
|
|
457
|
+
Optional link: "Licensing Explained"
|
|
458
|
+
|
|
459
|
+
Visual:
|
|
460
|
+
- needsImage: true
|
|
461
|
+
- imgQuery: "enterprise call to action abstract technology background dark"
|
|
462
|
+
|
|
463
|
+
---
|
|
464
|
+
|
|
465
|
+
## C) PAGE STUDIO RENDERING RULES
|
|
466
|
+
|
|
467
|
+
- Prose first, UI blocks second
|
|
468
|
+
- No compressed sections
|
|
469
|
+
- Maintain enterprise rhythm and spacing
|
|
470
|
+
- Ensure hero overlay is glassy and does NOT block the image
|
|
471
|
+
|
|
472
|
+
Failure to satisfy content depth or image rules is invalid.
|
|
473
|
+
|
|
474
|
+
"""
|
|
475
|
+
|
|
476
|
+
|
|
477
|
+
SMXAI_ABOUT_PAGE_INSTRUCTIONS = f"""
|
|
478
|
+
IMPORTANT CONTEXT FOR THE GENERATOR
|
|
479
|
+
This page must read like the About page of a serious infrastructure and design by the website desc.
|
|
480
|
+
This is NOT marketing copy. This is NOT a teaser. This is a full company profile.
|
|
481
|
+
Failure to follow layout, image, or depth requirements invalidates the output.
|
|
482
|
+
|
|
483
|
+
🔒 PLAN GENERATION CONTRACT (MANDATORY)
|
|
484
|
+
When generating the internal page plan JSON:
|
|
485
|
+
EVERY major section MUST explicitly include an image block
|
|
486
|
+
For EACH section, the planner MUST emit:
|
|
487
|
+
needsImage: true
|
|
488
|
+
|
|
489
|
+
imgQuery: "<specific, concrete image search query>"
|
|
490
|
+
Images must be attached at section level
|
|
491
|
+
Do NOT rely on defaults
|
|
492
|
+
If any section lacks needsImage + imgQuery, the plan is INVALID
|
|
493
|
+
|
|
494
|
+
This applies to:
|
|
495
|
+
hero
|
|
496
|
+
mission / vision
|
|
497
|
+
problem statement
|
|
498
|
+
platform architecture
|
|
499
|
+
capabilities
|
|
500
|
+
principles
|
|
501
|
+
founders
|
|
502
|
+
credibility / roadmap
|
|
503
|
+
final CTA
|
|
504
|
+
|
|
505
|
+
🎯 PAGE GOAL
|
|
506
|
+
Generate a comprehensive, long-form About page that explains:
|
|
507
|
+
What SyntaxMatrix is
|
|
508
|
+
Why it exists
|
|
509
|
+
What it builds (smxPP)
|
|
510
|
+
How the platform works internally
|
|
511
|
+
How it is deployed and governed
|
|
512
|
+
Who built it and why they are qualified
|
|
513
|
+
Why enterprises should trust it
|
|
514
|
+
Audience:
|
|
515
|
+
|
|
516
|
+
CTOs
|
|
517
|
+
Heads of Engineering
|
|
518
|
+
AI Architects
|
|
519
|
+
Enterprise Buyers
|
|
520
|
+
Technical Investors
|
|
521
|
+
|
|
522
|
+
Tone:
|
|
523
|
+
enterprise-grade
|
|
524
|
+
technical
|
|
525
|
+
confident
|
|
526
|
+
explanatory
|
|
527
|
+
sceptic-aware
|
|
528
|
+
never hype-driven
|
|
529
|
+
|
|
530
|
+
📐 GLOBAL CONTENT RULES (NON-NEGOTIABLE)
|
|
531
|
+
This page MUST be long-form prose
|
|
532
|
+
Each MAJOR section must include:
|
|
533
|
+
3-4 full paragraphs minimum
|
|
534
|
+
Each paragraph 6-7 sentences
|
|
535
|
+
Bullet points and cards are allowed ONLY as summaries
|
|
536
|
+
Prose explanations MUST come first
|
|
537
|
+
No slogans without explanation
|
|
538
|
+
Assume the reader is technically competent and distrustful
|
|
539
|
+
Thin content = failure.
|
|
540
|
+
|
|
541
|
+
🖼️ GLOBAL IMAGE RULES (NON-NEGOTIABLE)
|
|
542
|
+
Every MAJOR section MUST include an image
|
|
543
|
+
Images support comprehension — they do NOT replace text
|
|
544
|
+
|
|
545
|
+
Prefer:
|
|
546
|
+
architecture diagrams
|
|
547
|
+
abstract technical visuals
|
|
548
|
+
interfaces
|
|
549
|
+
|
|
550
|
+
Avoid:
|
|
551
|
+
lifestyle photos
|
|
552
|
+
generic startup imagery
|
|
553
|
+
Do NOT reuse images across sections
|
|
554
|
+
|
|
555
|
+
🧩 A) LAYOUT & HERO RULES
|
|
556
|
+
Hero Layout Options (EXPLICIT)
|
|
557
|
+
The generator MUST support both layouts:
|
|
558
|
+
Default: heroAlignment = "left"
|
|
559
|
+
Alternative: heroAlignment = "center"
|
|
560
|
+
The chosen alignment MUST be emitted in the plan.
|
|
561
|
+
Hero Overlay Rules (MANDATORY)
|
|
562
|
+
Overlay style MUST be glassy / translucent
|
|
563
|
+
NO opaque white cards
|
|
564
|
+
Overlay opacity should allow the hero image to remain visible
|
|
565
|
+
The hero image must visually dominate
|
|
566
|
+
|
|
567
|
+
🧱 B) REQUIRED SECTION STRUCTURE (IN ORDER)
|
|
568
|
+
B.1 Hero — Company Identity & Positioning
|
|
569
|
+
Content requirements:
|
|
570
|
+
|
|
571
|
+
3-4 paragraphs explaining:
|
|
572
|
+
what SyntaxMatrix is as a company
|
|
573
|
+
its focus on AI infrastructure and algorithm design
|
|
574
|
+
the difference between SyntaxMatrix and hosted AI tools
|
|
575
|
+
Clearly introduce smxPP as the core product
|
|
576
|
+
Explain “client-owned AI platforms” in concrete terms
|
|
577
|
+
|
|
578
|
+
CTAs:
|
|
579
|
+
“View Services”
|
|
580
|
+
“Read Documentation”
|
|
581
|
+
Visual:
|
|
582
|
+
needsImage: true
|
|
583
|
+
imgQuery: "enterprise AI infrastructure architecture abstract dark"
|
|
584
|
+
|
|
585
|
+
B.2 Mission and Vision
|
|
586
|
+
Mission:
|
|
587
|
+
2 paragraphs explaining what the company delivers today
|
|
588
|
+
|
|
589
|
+
Focus on engineering outcomes, not aspirations
|
|
590
|
+
|
|
591
|
+
Vision:
|
|
592
|
+
2 paragraphs explaining the long-term direction:
|
|
593
|
+
governed AI systems
|
|
594
|
+
composable platforms
|
|
595
|
+
ownership, auditability, control
|
|
596
|
+
Visual:
|
|
597
|
+
|
|
598
|
+
needsImage: true
|
|
599
|
+
|
|
600
|
+
imgQuery: "enterprise technology mission vision abstract diagram"
|
|
601
|
+
|
|
602
|
+
B.3 Why SyntaxMatrix Exists
|
|
603
|
+
Content requirements:
|
|
604
|
+
3-4 paragraphs describing industry pain points in depth:
|
|
605
|
+
repeated rebuilding of AI stacks
|
|
606
|
+
fragile RAG systems
|
|
607
|
+
lack of governance and audit trails
|
|
608
|
+
separation of AI from content systems
|
|
609
|
+
Follow with a short bullet summary
|
|
610
|
+
|
|
611
|
+
Visual:
|
|
612
|
+
needsImage: true
|
|
613
|
+
imgQuery: "enterprise AI complexity fragmentation diagram"
|
|
614
|
+
B.4 The smxPP Platform Architecture
|
|
615
|
+
Content requirements:
|
|
616
|
+
|
|
617
|
+
4-5 paragraphs explaining:
|
|
618
|
+
internal architecture of smxPP
|
|
619
|
+
subsystem interaction
|
|
620
|
+
why this design enables reuse and governance
|
|
621
|
+
Explicitly describe:
|
|
622
|
+
role-aware UI
|
|
623
|
+
document ingestion
|
|
624
|
+
|
|
625
|
+
RAG pipelines
|
|
626
|
+
|
|
627
|
+
Page Studio
|
|
628
|
+
|
|
629
|
+
ML Lab
|
|
630
|
+
|
|
631
|
+
vector stores
|
|
632
|
+
|
|
633
|
+
licensing boundaries
|
|
634
|
+
|
|
635
|
+
Visual:
|
|
636
|
+
|
|
637
|
+
needsImage: true
|
|
638
|
+
|
|
639
|
+
imgQuery: "AI platform architecture diagram UI RAG ML pipeline"
|
|
640
|
+
|
|
641
|
+
B.5 Core Capabilities
|
|
642
|
+
|
|
643
|
+
Intro:
|
|
644
|
+
|
|
645
|
+
2 paragraphs explaining the capability philosophy
|
|
646
|
+
|
|
647
|
+
For EACH capability:
|
|
648
|
+
|
|
649
|
+
1 paragraph explaining what it does
|
|
650
|
+
|
|
651
|
+
1 paragraph explaining why it matters operationally
|
|
652
|
+
|
|
653
|
+
Capabilities:
|
|
654
|
+
|
|
655
|
+
Chat assistant (tools, RAG, streaming)
|
|
656
|
+
|
|
657
|
+
Document ingestion & retrieval
|
|
658
|
+
|
|
659
|
+
Page Studio
|
|
660
|
+
|
|
661
|
+
Documentation viewer
|
|
662
|
+
|
|
663
|
+
ML Lab & exports
|
|
664
|
+
|
|
665
|
+
Vector store upgrades
|
|
666
|
+
|
|
667
|
+
Visuals:
|
|
668
|
+
|
|
669
|
+
needsImage: true per capability
|
|
670
|
+
|
|
671
|
+
imgQuery aligned per capability (specific, technical)
|
|
672
|
+
|
|
673
|
+
B.6 Operating Principles
|
|
674
|
+
|
|
675
|
+
Content requirements:
|
|
676
|
+
|
|
677
|
+
Intro paragraph on why principles matter in AI systems
|
|
678
|
+
|
|
679
|
+
Each principle:
|
|
680
|
+
|
|
681
|
+
short title
|
|
682
|
+
|
|
683
|
+
3–4 sentence explanation
|
|
684
|
+
|
|
685
|
+
No slogans without substance
|
|
686
|
+
|
|
687
|
+
Visual:
|
|
688
|
+
|
|
689
|
+
needsImage: true
|
|
690
|
+
|
|
691
|
+
imgQuery: "engineering principles abstract geometric"
|
|
692
|
+
|
|
693
|
+
B.7 Founders & Governance
|
|
694
|
+
|
|
695
|
+
Content requirements:
|
|
696
|
+
|
|
697
|
+
Intro paragraph on leadership and accountability
|
|
698
|
+
|
|
699
|
+
Bobga Nti — Founder / AI Engineer
|
|
700
|
+
|
|
701
|
+
Detailed paragraph on background, system design focus, and role
|
|
702
|
+
|
|
703
|
+
Yvonne Motuba — Company Secretary
|
|
704
|
+
|
|
705
|
+
Paragraph on governance, compliance, and organisational stability
|
|
706
|
+
|
|
707
|
+
This section MUST explicitly address trust and credibility
|
|
708
|
+
|
|
709
|
+
Visual:
|
|
710
|
+
|
|
711
|
+
needsImage: true
|
|
712
|
+
|
|
713
|
+
imgQuery: "professional executive portrait neutral background"
|
|
714
|
+
|
|
715
|
+
B.8 Credibility, Premium Capabilities & Roadmap
|
|
716
|
+
|
|
717
|
+
Content requirements:
|
|
718
|
+
|
|
719
|
+
2 paragraphs on current production capabilities
|
|
720
|
+
|
|
721
|
+
2 paragraphs on premium / enterprise features:
|
|
722
|
+
|
|
723
|
+
licensing
|
|
724
|
+
|
|
725
|
+
audit
|
|
726
|
+
|
|
727
|
+
deployment control
|
|
728
|
+
|
|
729
|
+
1–2 paragraphs on roadmap direction
|
|
730
|
+
|
|
731
|
+
No over-promising
|
|
732
|
+
|
|
733
|
+
Visual:
|
|
734
|
+
|
|
735
|
+
needsImage: true
|
|
736
|
+
|
|
737
|
+
imgQuery: "enterprise product roadmap timeline minimal"
|
|
738
|
+
|
|
739
|
+
B.9 FAQ
|
|
740
|
+
|
|
741
|
+
Requirements:
|
|
742
|
+
|
|
743
|
+
5–7 FAQs
|
|
744
|
+
|
|
745
|
+
Each answer 2–3 sentences
|
|
746
|
+
|
|
747
|
+
Must include:
|
|
748
|
+
|
|
749
|
+
What is a client instance?
|
|
750
|
+
|
|
751
|
+
Where does data live?
|
|
752
|
+
|
|
753
|
+
Can we deploy privately?
|
|
754
|
+
|
|
755
|
+
How licensing works?
|
|
756
|
+
|
|
757
|
+
What premium provides?
|
|
758
|
+
|
|
759
|
+
Visual: optional
|
|
760
|
+
|
|
761
|
+
B.10 Final CTA
|
|
762
|
+
|
|
763
|
+
Content requirements:
|
|
764
|
+
|
|
765
|
+
1 paragraph reinforcing value and deployment model
|
|
766
|
+
|
|
767
|
+
Clear next steps
|
|
768
|
+
|
|
769
|
+
CTAs:
|
|
770
|
+
|
|
771
|
+
“Talk to SyntaxMatrix”
|
|
772
|
+
|
|
773
|
+
“View Documentation”
|
|
774
|
+
|
|
775
|
+
Visual:
|
|
776
|
+
|
|
777
|
+
needsImage: true
|
|
778
|
+
|
|
779
|
+
imgQuery: "enterprise AI call to action abstract technology"
|
|
780
|
+
|
|
781
|
+
🛠️ C) PAGE STUDIO RENDERING RULES
|
|
782
|
+
|
|
783
|
+
Narrative prose first, UI blocks second
|
|
784
|
+
|
|
785
|
+
Cards summarise; paragraphs explain
|
|
786
|
+
|
|
787
|
+
No section should feel compressed
|
|
788
|
+
|
|
789
|
+
The page must read like a full company profile
|
|
790
|
+
|
|
791
|
+
✅ END OF INSTRUCTIONS
|
|
792
|
+
"""
|
|
793
|
+
|
|
794
|
+
|
|
795
|
+
SMXAI_SERVICES_PAGE_INSTRUCTIONS = """
|
|
796
|
+
✅ SMXAI_SERVICES_PAGE_INSTRUCTIONS — FINAL (ENTERPRISE, IMAGE-SAFE
|
|
797
|
+
IMPORTANT CONTEXT FOR THE GENERATOR
|
|
798
|
+
|
|
799
|
+
SyntaxMatrix is the company.
|
|
800
|
+
SyntaxMatrix Platform Provisioner (smxPP) is the product.
|
|
801
|
+
This page describes what SyntaxMatrix delivers to organisations, not features in isolation.
|
|
802
|
+
This is an enterprise services page, not a SaaS pricing teaser.
|
|
803
|
+
|
|
804
|
+
🔒 PLAN GENERATION CONTRACT (MANDATORY)
|
|
805
|
+
When generating the page plan JSON:
|
|
806
|
+
EVERY major section MUST explicitly include an image
|
|
807
|
+
For EACH section, the planner MUST emit:
|
|
808
|
+
needsImage: true
|
|
809
|
+
imgQuery: "<specific, concrete image search query>"
|
|
810
|
+
Images MUST be attached at section level
|
|
811
|
+
Do NOT rely on default templates
|
|
812
|
+
If any section lacks needsImage + imgQuery, the plan is INVALID
|
|
813
|
+
This applies to:
|
|
814
|
+
|
|
815
|
+
hero
|
|
816
|
+
service categories
|
|
817
|
+
deployment models
|
|
818
|
+
premium services
|
|
819
|
+
licensing
|
|
820
|
+
enterprise engagement
|
|
821
|
+
final CTA
|
|
822
|
+
|
|
823
|
+
🎯 PAGE GOAL
|
|
824
|
+
Generate a long-form, enterprise Services page that explains:
|
|
825
|
+
What services SyntaxMatrix provides
|
|
826
|
+
How smxPP is delivered, deployed, and governed
|
|
827
|
+
What premium and enterprise plans unlock
|
|
828
|
+
How licensing works in practice
|
|
829
|
+
Why enterprises trust this model
|
|
830
|
+
Audience:
|
|
831
|
+
|
|
832
|
+
CTOs
|
|
833
|
+
Heads of Engineering
|
|
834
|
+
Enterprise Architects
|
|
835
|
+
Procurement & Compliance teams
|
|
836
|
+
Technical buyers
|
|
837
|
+
|
|
838
|
+
Tone:
|
|
839
|
+
enterprise-first
|
|
840
|
+
technical
|
|
841
|
+
precise
|
|
842
|
+
confident
|
|
843
|
+
operational, not promotional
|
|
844
|
+
|
|
845
|
+
📐 GLOBAL CONTENT RULES (NON-NEGOTIABLE)
|
|
846
|
+
This page MUST be long-form prose
|
|
847
|
+
Each MAJOR section must include:
|
|
848
|
+
|
|
849
|
+
3-4 full paragraphs minimum
|
|
850
|
+
|
|
851
|
+
Each paragraph 6-8 sentences
|
|
852
|
+
|
|
853
|
+
Cards and bullets are allowed ONLY as summaries
|
|
854
|
+
|
|
855
|
+
Prose explanations MUST come first
|
|
856
|
+
|
|
857
|
+
Avoid slogans
|
|
858
|
+
|
|
859
|
+
Assume sceptical, technical readers
|
|
860
|
+
|
|
861
|
+
Thin or marketing-style content = failure.
|
|
862
|
+
|
|
863
|
+
🖼️ GLOBAL IMAGE RULES (NON-NEGOTIABLE)
|
|
864
|
+
|
|
865
|
+
Every MAJOR section MUST include a visual
|
|
866
|
+
|
|
867
|
+
Images support comprehension
|
|
868
|
+
|
|
869
|
+
Prefer:
|
|
870
|
+
|
|
871
|
+
architecture diagrams
|
|
872
|
+
|
|
873
|
+
deployment diagrams
|
|
874
|
+
|
|
875
|
+
governance visuals
|
|
876
|
+
|
|
877
|
+
Avoid:
|
|
878
|
+
|
|
879
|
+
lifestyle imagery
|
|
880
|
+
|
|
881
|
+
abstract “startup” photos
|
|
882
|
+
|
|
883
|
+
🧩 A) LAYOUT & HERO RULES
|
|
884
|
+
Hero Layout Options
|
|
885
|
+
|
|
886
|
+
The generator MUST support:
|
|
887
|
+
|
|
888
|
+
heroAlignment = "left"
|
|
889
|
+
|
|
890
|
+
heroAlignment = "center"
|
|
891
|
+
|
|
892
|
+
One must be explicitly selected.
|
|
893
|
+
|
|
894
|
+
Hero Overlay Rules
|
|
895
|
+
|
|
896
|
+
Overlay MUST be glassy / translucent
|
|
897
|
+
|
|
898
|
+
NO opaque white banners
|
|
899
|
+
|
|
900
|
+
Hero image must remain visible and dominant
|
|
901
|
+
|
|
902
|
+
🧱 B) REQUIRED SECTION STRUCTURE (IN ORDER)
|
|
903
|
+
B.1 Hero — Services Overview
|
|
904
|
+
|
|
905
|
+
Content requirements:
|
|
906
|
+
|
|
907
|
+
2–3 paragraphs explaining:
|
|
908
|
+
|
|
909
|
+
SyntaxMatrix’s service philosophy
|
|
910
|
+
|
|
911
|
+
Why services are centred around platform provisioning, not one-off builds
|
|
912
|
+
|
|
913
|
+
How smxPP underpins all service offerings
|
|
914
|
+
|
|
915
|
+
Clearly state that services scale from pilot to enterprise
|
|
916
|
+
|
|
917
|
+
CTAs:
|
|
918
|
+
|
|
919
|
+
“Explore Plans”
|
|
920
|
+
|
|
921
|
+
“Talk to Engineering”
|
|
922
|
+
|
|
923
|
+
Visual:
|
|
924
|
+
|
|
925
|
+
needsImage: true
|
|
926
|
+
|
|
927
|
+
imgQuery: "enterprise AI services platform architecture dark"
|
|
928
|
+
|
|
929
|
+
B.2 Platform Provisioning Services
|
|
930
|
+
|
|
931
|
+
Content requirements:
|
|
932
|
+
|
|
933
|
+
3 paragraphs explaining:
|
|
934
|
+
|
|
935
|
+
What it means to provision a client-owned AI platform
|
|
936
|
+
|
|
937
|
+
How smxPP is delivered into a client environment
|
|
938
|
+
|
|
939
|
+
How this differs from hosted AI tools
|
|
940
|
+
|
|
941
|
+
Explicitly cover:
|
|
942
|
+
|
|
943
|
+
runtime ownership
|
|
944
|
+
|
|
945
|
+
data locality
|
|
946
|
+
|
|
947
|
+
security boundary control
|
|
948
|
+
|
|
949
|
+
Visual:
|
|
950
|
+
|
|
951
|
+
needsImage: true
|
|
952
|
+
|
|
953
|
+
imgQuery: "client owned AI platform deployment architecture diagram"
|
|
954
|
+
|
|
955
|
+
B.3 Deployment Models
|
|
956
|
+
|
|
957
|
+
Content requirements:
|
|
958
|
+
|
|
959
|
+
2–3 paragraphs explaining supported deployment modes:
|
|
960
|
+
|
|
961
|
+
on-premise
|
|
962
|
+
|
|
963
|
+
private cloud
|
|
964
|
+
|
|
965
|
+
regulated environments
|
|
966
|
+
|
|
967
|
+
Explain operational implications of each
|
|
968
|
+
|
|
969
|
+
Follow with a short comparison list
|
|
970
|
+
|
|
971
|
+
Visual:
|
|
972
|
+
|
|
973
|
+
needsImage: true
|
|
974
|
+
|
|
975
|
+
imgQuery: "enterprise deployment models on premise cloud diagram"
|
|
976
|
+
|
|
977
|
+
B.4 Core Service Domains
|
|
978
|
+
|
|
979
|
+
Intro:
|
|
980
|
+
|
|
981
|
+
2 paragraphs explaining how services map to enterprise needs
|
|
982
|
+
|
|
983
|
+
For EACH domain:
|
|
984
|
+
|
|
985
|
+
1 paragraph explaining what is delivered
|
|
986
|
+
|
|
987
|
+
1 paragraph explaining business impact
|
|
988
|
+
|
|
989
|
+
Domains include:
|
|
990
|
+
|
|
991
|
+
AI Assistant & RAG Systems
|
|
992
|
+
|
|
993
|
+
Document Ingestion & Knowledge Architecture
|
|
994
|
+
|
|
995
|
+
Page Studio & Internal Portals
|
|
996
|
+
|
|
997
|
+
ML Lab & Model Workflows
|
|
998
|
+
|
|
999
|
+
Vector Store Engineering
|
|
1000
|
+
|
|
1001
|
+
Visual:
|
|
1002
|
+
|
|
1003
|
+
needsImage: true per domain
|
|
1004
|
+
|
|
1005
|
+
imgQuery aligned to each domain (technical, specific)
|
|
1006
|
+
|
|
1007
|
+
B.5 Premium & Enterprise Capabilities
|
|
1008
|
+
|
|
1009
|
+
Content requirements:
|
|
1010
|
+
|
|
1011
|
+
3 paragraphs explaining:
|
|
1012
|
+
|
|
1013
|
+
what premium unlocks beyond free/trial
|
|
1014
|
+
|
|
1015
|
+
why these features matter operationally
|
|
1016
|
+
|
|
1017
|
+
MUST include:
|
|
1018
|
+
|
|
1019
|
+
licensing enforcement
|
|
1020
|
+
|
|
1021
|
+
auditability
|
|
1022
|
+
|
|
1023
|
+
entitlement gating
|
|
1024
|
+
|
|
1025
|
+
advanced vector backends
|
|
1026
|
+
|
|
1027
|
+
ML exports
|
|
1028
|
+
|
|
1029
|
+
Visual:
|
|
1030
|
+
|
|
1031
|
+
needsImage: true
|
|
1032
|
+
|
|
1033
|
+
imgQuery: "enterprise AI premium features governance diagram"
|
|
1034
|
+
|
|
1035
|
+
B.6 Licensing & Governance Services
|
|
1036
|
+
|
|
1037
|
+
Content requirements:
|
|
1038
|
+
|
|
1039
|
+
3 paragraphs explaining:
|
|
1040
|
+
|
|
1041
|
+
the licensing model
|
|
1042
|
+
|
|
1043
|
+
remote licence validation
|
|
1044
|
+
|
|
1045
|
+
fraud prevention and entitlement control
|
|
1046
|
+
|
|
1047
|
+
Emphasise:
|
|
1048
|
+
|
|
1049
|
+
enterprise trust
|
|
1050
|
+
|
|
1051
|
+
subscription integrity
|
|
1052
|
+
|
|
1053
|
+
offline and controlled environments
|
|
1054
|
+
|
|
1055
|
+
Visual:
|
|
1056
|
+
|
|
1057
|
+
needsImage: true
|
|
1058
|
+
|
|
1059
|
+
imgQuery: "enterprise software licensing governance security diagram"
|
|
1060
|
+
|
|
1061
|
+
B.7 Engagement & Support Model
|
|
1062
|
+
|
|
1063
|
+
Content requirements:
|
|
1064
|
+
|
|
1065
|
+
2–3 paragraphs explaining:
|
|
1066
|
+
|
|
1067
|
+
onboarding
|
|
1068
|
+
|
|
1069
|
+
technical enablement
|
|
1070
|
+
|
|
1071
|
+
long-term support
|
|
1072
|
+
|
|
1073
|
+
Explain how SyntaxMatrix works with engineering teams, not replaces them
|
|
1074
|
+
|
|
1075
|
+
Visual:
|
|
1076
|
+
|
|
1077
|
+
needsImage: true
|
|
1078
|
+
|
|
1079
|
+
imgQuery: "enterprise engineering collaboration workflow diagram"
|
|
1080
|
+
|
|
1081
|
+
B.8 Plans Overview (Narrative, Not Pricing Table)
|
|
1082
|
+
|
|
1083
|
+
Content requirements:
|
|
1084
|
+
|
|
1085
|
+
2 paragraphs explaining plan philosophy:
|
|
1086
|
+
|
|
1087
|
+
Free / Trial
|
|
1088
|
+
|
|
1089
|
+
Pro
|
|
1090
|
+
|
|
1091
|
+
Business
|
|
1092
|
+
|
|
1093
|
+
Enterprise
|
|
1094
|
+
|
|
1095
|
+
No prices here — explain capability progression
|
|
1096
|
+
|
|
1097
|
+
Visual:
|
|
1098
|
+
|
|
1099
|
+
needsImage: true
|
|
1100
|
+
|
|
1101
|
+
imgQuery: "enterprise service tiers progression diagram"
|
|
1102
|
+
|
|
1103
|
+
B.9 Enterprise Trust & Compliance
|
|
1104
|
+
|
|
1105
|
+
Content requirements:
|
|
1106
|
+
|
|
1107
|
+
2 paragraphs addressing:
|
|
1108
|
+
|
|
1109
|
+
data ownership
|
|
1110
|
+
|
|
1111
|
+
auditability
|
|
1112
|
+
|
|
1113
|
+
deployment control
|
|
1114
|
+
|
|
1115
|
+
regulatory alignment
|
|
1116
|
+
|
|
1117
|
+
This section MUST explicitly reassure enterprise buyers
|
|
1118
|
+
|
|
1119
|
+
Visual:
|
|
1120
|
+
|
|
1121
|
+
needsImage: true
|
|
1122
|
+
|
|
1123
|
+
imgQuery: "enterprise compliance security audit abstract diagram"
|
|
1124
|
+
|
|
1125
|
+
B.10 Final CTA
|
|
1126
|
+
|
|
1127
|
+
Content requirements:
|
|
1128
|
+
|
|
1129
|
+
1 paragraph reinforcing service value
|
|
1130
|
+
|
|
1131
|
+
Clear next steps
|
|
1132
|
+
|
|
1133
|
+
CTAs:
|
|
1134
|
+
|
|
1135
|
+
“Talk to SyntaxMatrix”
|
|
1136
|
+
|
|
1137
|
+
“View Licensing Explained”
|
|
1138
|
+
|
|
1139
|
+
Visual:
|
|
1140
|
+
|
|
1141
|
+
needsImage: true
|
|
1142
|
+
|
|
1143
|
+
imgQuery: "enterprise AI consultation call to action abstract"
|
|
1144
|
+
|
|
1145
|
+
🛠️ C) PAGE STUDIO RENDERING RULES
|
|
1146
|
+
|
|
1147
|
+
Prose first, cards second
|
|
1148
|
+
|
|
1149
|
+
No compressed sections
|
|
1150
|
+
|
|
1151
|
+
Page must read like a consulting-grade services document
|
|
1152
|
+
|
|
1153
|
+
✅ END OF INSTRUCTIONS
|
|
1154
|
+
"""
|
|
1155
|
+
|
|
1156
|
+
|
|
1157
|
+
SMXAI_SERVICES_PAGE_INSTRUCTIONS_2 = """
|
|
1158
|
+
You are generating a SERVICES page for SyntaxMatrix.
|
|
1159
|
+
|
|
1160
|
+
GOAL
|
|
1161
|
+
Create a clear, professional services page that explains:
|
|
1162
|
+
- what services SyntaxMatrix provides
|
|
1163
|
+
- how those services are delivered
|
|
1164
|
+
- who they are for
|
|
1165
|
+
- how a client engages or starts a conversation
|
|
1166
|
+
|
|
1167
|
+
This page must read like an enterprise AI engineering firm, not a marketing brochure.
|
|
1168
|
+
|
|
1169
|
+
ABSOLUTE REQUIREMENTS
|
|
1170
|
+
1) The plan MUST include a hero section (type: "hero") with:
|
|
1171
|
+
- a concise headline describing what SyntaxMatrix delivers (AI systems, RAG frameworks, agentic platforms, etc.)
|
|
1172
|
+
- a short subheading (1–2 sentences) explaining the value proposition
|
|
1173
|
+
- a primary CTA such as "Request a consultation" or "Talk to us"
|
|
1174
|
+
|
|
1175
|
+
2) The plan MUST include a core services section using type: "features".
|
|
1176
|
+
This section must list 4–7 services.
|
|
1177
|
+
Each service must be presented as a compact, scannable card with:
|
|
1178
|
+
- clear service title
|
|
1179
|
+
- short description (1–2 sentences max)
|
|
1180
|
+
- what the client gets (outcome-focused, not buzzwords)
|
|
1181
|
+
|
|
1182
|
+
3) The plan MUST include a "How we work" section using type: "richtext" or "features".
|
|
1183
|
+
It should explain the engagement model in 4–6 steps:
|
|
1184
|
+
- discovery / requirements
|
|
1185
|
+
- system design
|
|
1186
|
+
- implementation
|
|
1187
|
+
- evaluation & testing
|
|
1188
|
+
- deployment
|
|
1189
|
+
- support / iteration (if applicable)
|
|
1190
|
+
|
|
1191
|
+
4) The plan MUST include a "Who this is for" or "Use cases" section.
|
|
1192
|
+
Use type: "features" or "richtext".
|
|
1193
|
+
Examples:
|
|
1194
|
+
- startups building AI products
|
|
1195
|
+
- enterprises adopting internal AI tools
|
|
1196
|
+
- educators / training providers
|
|
1197
|
+
- research or applied AI teams
|
|
1198
|
+
|
|
1199
|
+
5) The plan MUST include a final CTA section (type: "cta") with:
|
|
1200
|
+
- a clear invitation to engage
|
|
1201
|
+
- what to provide when contacting (brief description, goals, constraints)
|
|
1202
|
+
- a placeholder contact method (email / form)
|
|
1203
|
+
|
|
1204
|
+
CONTENT CONSTRAINTS
|
|
1205
|
+
- Do NOT claim one-size-fits-all solutions.
|
|
1206
|
+
- Do NOT invent client names, testimonials, or certifications.
|
|
1207
|
+
- Avoid exaggerated claims.
|
|
1208
|
+
- Keep descriptions concrete and grounded in engineering reality.
|
|
1209
|
+
- Avoid long paragraphs; use structured, skimmable copy.
|
|
1210
|
+
|
|
1211
|
+
SERVICE CATEGORIES (use as guidance)
|
|
1212
|
+
The services section may include items such as:
|
|
1213
|
+
- AI system architecture & design
|
|
1214
|
+
- Retrieval-Augmented Generation (RAG) systems
|
|
1215
|
+
- Multi-agent workflows and orchestration
|
|
1216
|
+
- Custom AI framework development (SyntaxMatrix-based)
|
|
1217
|
+
- Evaluation, testing, and reliability tooling
|
|
1218
|
+
- Deployment, MLOps, and infrastructure support
|
|
1219
|
+
- Custom fine-tuning of open-source models (privacy-focused)
|
|
1220
|
+
|
|
1221
|
+
SERVICE CARD TEMPLATE (features item)
|
|
1222
|
+
Each service should follow this shape:
|
|
1223
|
+
{
|
|
1224
|
+
"id": "svc_1",
|
|
1225
|
+
"type": "card",
|
|
1226
|
+
"title": "RAG System Design & Implementation",
|
|
1227
|
+
"text": "Design and build production-grade RAG pipelines with reliable retrieval, evaluation, and context control."
|
|
1228
|
+
}
|
|
1229
|
+
|
|
1230
|
+
STYLE
|
|
1231
|
+
- Confident, technical, and professional.
|
|
1232
|
+
- Emphasise SyntaxMatrix as an AI algorithm design and framework company.
|
|
1233
|
+
- Assume a technically literate audience (CTOs, engineers, decision-makers).
|
|
1234
|
+
- Avoid hype; focus on capability and process.
|
|
1235
|
+
|
|
1236
|
+
RECOMMENDED PAGE STRUCTURE
|
|
1237
|
+
1) hero
|
|
1238
|
+
2) features: Core services
|
|
1239
|
+
3) richtext/features: How we work
|
|
1240
|
+
4) features/richtext: Who this is for / Use cases
|
|
1241
|
+
5) cta
|
|
1242
|
+
|
|
1243
|
+
OUTPUT QUALITY CHECK
|
|
1244
|
+
Before finalising, ensure:
|
|
1245
|
+
- Services are clearly enumerated.
|
|
1246
|
+
- Engagement process is explicit.
|
|
1247
|
+
- CTA is actionable and clear.
|
|
1248
|
+
"""
|
|
99
1249
|
|
|
100
|
-
Company Overview
|
|
101
|
-
Corporate Identity
|
|
102
|
-
Company Name: SyntaxMatrix (trading name)
|
|
103
|
-
Legal Entity: SyntaxMatrix Limited (Ireland)
|
|
104
|
-
Founded: 2025
|
|
105
|
-
Headquarters: Ireland
|
|
106
|
-
Website: https://syntaxmatrix.net
|
|
107
|
-
Contact:
|
|
108
|
-
General: info@syntaxmatrix.net
|
|
109
|
-
Support: support@syntaxmatrix.net
|
|
110
|
-
Sales: sales@syntaxmatrix.net
|
|
111
|
-
Founder & CEO: Bobga Nti (MSc in Artificial Intelligence)
|
|
112
|
-
|
|
113
|
-
1.2 Company Description
|
|
114
|
-
SyntaxMatrix Limited is an Ireland-based AI engineering company that builds and ships AI frameworks for provisioning client-ready AI platforms. The SyntaxMatrix Framework combines a chat assistant, Admin Panel, knowledge base ingestion, webpage generation and management studio, and a Machine Learning Lab so teams can deliver complete AI systems without rebuilding the foundation for every client.
|
|
115
|
-
|
|
116
|
-
1.3 Industry Positioning
|
|
117
|
-
SyntaxMatrix is industry-agnostic, with the same platform pattern working for:
|
|
118
|
-
Education
|
|
119
|
-
Healthcare
|
|
120
|
-
Legal
|
|
121
|
-
Finance
|
|
122
|
-
Retail
|
|
123
|
-
Public sector
|
|
124
|
-
Internal enterprise tools
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
2. Mission, Vision & Values
|
|
128
|
-
2.1 Mission
|
|
129
|
-
Help teams ship AI platforms faster with a framework that is simple to operate, easy to extend, and safe to deploy.
|
|
130
|
-
2.2 Vision
|
|
131
|
-
AI platforms should be provisioned like infrastructure: consistent, repeatable, and ready for real workflows.
|
|
132
|
-
|
|
133
|
-
2.3 Core Values
|
|
134
|
-
Clarity first: Simple systems teams can reason about
|
|
135
|
-
Engineering rigour: Code review, tests, and measurable quality gates
|
|
136
|
-
Security by default: Least privilege, safe secrets handling, audit trails
|
|
137
|
-
Customer empathy: Build for real workflows, not demo-only flows
|
|
138
|
-
Responsible AI: Transparency, privacy, and operational control
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
3. Leadership Team
|
|
142
|
-
3.1 Executive Leadership
|
|
143
|
-
Bobga Nti: Chief Executive Officer (CEO) & Founder
|
|
144
|
-
Niall Byrne: Chief Technology Officer (CTO)
|
|
145
|
-
Aoife O'Sullivan: Chief Operating Officer (COO)
|
|
146
|
-
|
|
147
|
-
3.2 Department Heads
|
|
148
|
-
Priya Menon: Head of AI Engineering
|
|
149
|
-
Sinead Walsh: Head of Product
|
|
150
|
-
Farah Hassan: Security & Compliance Officer
|
|
151
|
-
Emma Kavanagh: Head of Sales & Partnerships
|
|
152
|
-
Maeve Gallagher: Customer Success Lead
|
|
153
|
-
|
|
154
|
-
3.3 Technical Team
|
|
155
|
-
Daniel Okafor: Principal AI Engineer
|
|
156
|
-
Luca Romano: Lead Software Engineer (Web Platform & Page Studio)
|
|
157
|
-
Tomasz Nowak: DevOps & Cloud Engineer
|
|
158
|
-
Yusuf Al-Khatib: Solutions Architect
|
|
159
|
-
|
|
160
|
-
|
|
161
|
-
4. The SyntaxMatrix Framework
|
|
162
|
-
4.1 Product Summary
|
|
163
|
-
The SyntaxMatrix is a framework for provisioning AI platforms per client. It enables Mixture-of-Experts (MoE) routing where each task is directed to the best-fit model profile.
|
|
164
|
-
4.2 Core Modules
|
|
165
|
-
4.2.1 Chat Assistant (smxAI)
|
|
166
|
-
Conversation UI with memory
|
|
167
|
-
Answers grounded in system documents via RAG (Retrieval Augmented Generation)
|
|
168
|
-
Integration with ML Lab outputs
|
|
169
|
-
4.2.2 Knowledge Base Ingestion
|
|
170
|
-
Automated PDF upload, text extraction, and chunking
|
|
171
|
-
Semantic search with embeddings
|
|
172
|
-
Separate knowledge bases per client deployment
|
|
173
|
-
4.2.3 Admin Panel
|
|
174
|
-
User and role management (user, employee, admin, superadmin + custom roles)
|
|
175
|
-
Secrets management for API keys and configuration
|
|
176
|
-
System document ingestion pipeline
|
|
177
|
-
Page management and publishing workflow
|
|
178
|
-
Media uploads and metadata
|
|
179
|
-
4.2.4 Page Studio (AI Webpage Generation)
|
|
180
|
-
AI-assisted page layout generation from slugs and site descriptions
|
|
181
|
-
Template based compilation with consistent visual style
|
|
182
|
-
Section level patching of existing pages
|
|
183
|
-
Optional image fill via Pixabay queries
|
|
184
|
-
Safe publishing guards (unsafe CTA links removed by default)
|
|
185
|
-
4.2.5 ML Lab
|
|
186
|
-
Dataset upload (CSV) and selection for analysis
|
|
187
|
-
EDA tables and plots rendered in UI
|
|
188
|
-
Code generation through dedicated coder profile
|
|
189
|
-
Execution in managed kernel with captured outputs
|
|
190
|
-
|
|
191
|
-
4.3 Mixture-of-Experts Profiles
|
|
192
|
-
SyntaxMatrix uses multiple model profiles for cost control and specialisation:
|
|
193
|
-
Admin profile: Concise operational answers
|
|
194
|
-
Chat profile: General assistant responses
|
|
195
|
-
Classifier profile: Intent detection and routing
|
|
196
|
-
Summariser profile: Document and conversation summarization
|
|
197
|
-
Coder/ML profile: Analysis and engineering code
|
|
198
|
-
Page Studio developer profile: Page layouts and section structure
|
|
199
|
-
Image profile: Image-related tasks
|
|
200
|
-
|
|
201
|
-
|
|
202
|
-
5. Technical Architecture
|
|
203
|
-
5.1 System Overview
|
|
204
|
-
SyntaxMatrix runs as a Flask web application with:
|
|
205
|
-
UI scaffolding and role-aware access
|
|
206
|
-
Local persistence (SQLite)
|
|
207
|
-
Knowledge base ingestion
|
|
208
|
-
Page generation system
|
|
209
|
-
ML Lab execution environment
|
|
210
|
-
|
|
211
|
-
5.2 Key Code Modules
|
|
212
|
-
Core/Routes: Flask app runtime and route wiring
|
|
213
|
-
Auth: Authentication, roles, and audit logging
|
|
214
|
-
File Processor: PDF extraction and chunk preparation
|
|
215
|
-
Vectorizer: Embedding generation
|
|
216
|
-
Vector DB: Persistent embeddings store (SQLite, PostgresSQL)
|
|
217
|
-
History Store: Chat persistence for users
|
|
218
|
-
Kernel Manager: Managed kernel execution for ML Lab
|
|
219
|
-
|
|
220
|
-
5.3 Page Studio Implementation
|
|
221
|
-
Page Builder: Builds layout JSON with image fill
|
|
222
|
-
Pages Layout Contractor: Normalises and validates layouts before publishing
|
|
223
|
-
Published Page Patcher: Applies safe section level patches with link sanitisation
|
|
224
|
-
Page Editor: Page editing, sorting, and drag-and-drop page widgets for page updates.
|
|
225
|
-
|
|
226
|
-
5.4 Knowledge Base Implementation
|
|
227
|
-
PDF text extraction via PyPDF2
|
|
228
|
-
Default chunking: recursive split with 2500-character max
|
|
229
|
-
Embeddings stored in SQLite with metadata
|
|
230
|
-
Tenant-scoped at deployment level (per client instance)
|
|
231
|
-
|
|
232
|
-
|
|
233
|
-
6. Security, Privacy & Compliance
|
|
234
|
-
6.1 Security Model
|
|
235
|
-
Designed for controlled deployments with robust access control
|
|
236
|
-
Default storage: SQLite within client instance directory
|
|
237
|
-
Organizations may add network controls and central identity providers
|
|
238
|
-
|
|
239
|
-
6.2 Authentication & Roles
|
|
240
|
-
Users stored in SQLite with hashed passwords (Server DB (premium)
|
|
241
|
-
Role hierarchy: user, employee, admin, superadmin + custom roles
|
|
242
|
-
Initial superadmin ('ceo') seeded with credentials in superadmin_credentials.txt
|
|
243
|
-
All role changes recorded in audit table
|
|
244
|
-
|
|
245
|
-
6.3 Secrets Management
|
|
246
|
-
API keys stored in dedicated SQLite table
|
|
247
|
-
Keys scoped tightly, rotated regularly
|
|
248
|
-
Never output in chat responses
|
|
249
|
-
|
|
250
|
-
6.4 Privacy Posture
|
|
251
|
-
Upload only documents with proper processing rights
|
|
252
|
-
Deployments isolated per client for data separation
|
|
253
|
-
Provider settings aligned with data retention requirements
|
|
254
|
-
|
|
255
|
-
|
|
256
|
-
7. Deployment & Provisioning
|
|
257
|
-
7.1 Provisioning Model
|
|
258
|
-
SyntaxMatrix is typically provisioned per client as separate deployments, each with:
|
|
259
|
-
Own instance directory
|
|
260
|
-
Dedicated databases
|
|
261
|
-
Separate uploaded documents and pages
|
|
262
|
-
Independent configuration
|
|
263
|
-
|
|
264
|
-
7.2 Per-Client Deployment Benefits
|
|
265
|
-
Simplified data isolation and access control
|
|
266
|
-
Controlled upgrade rollout per client
|
|
267
|
-
Predictable operations for agencies serving multiple clients
|
|
268
|
-
|
|
269
|
-
7.3 Provisioning Checklist
|
|
270
|
-
Create new client instance directory
|
|
271
|
-
Configure model profiles and API keys
|
|
272
|
-
Create admin/employee accounts with password reset enforcement
|
|
273
|
-
Upload system/company documents and validate retrieval
|
|
274
|
-
Create/generate pages using Page Studio
|
|
275
|
-
Upload dataset and validate ML Lab tasks
|
|
276
|
-
|
|
277
|
-
|
|
278
|
-
8. Pricing & Licensing
|
|
279
|
-
8.1 Bring-Your-Own-Key (BYOK) Model
|
|
280
|
-
7-day free trial: Full feature access with your provider keys
|
|
281
|
-
After trial: €149/month per client deployment
|
|
282
|
-
Includes framework updates and basic support
|
|
283
|
-
Model/embedding usage billed directly by your providers
|
|
284
|
-
Annual option: Pay yearly, get 2 months free (~16-17% discount)
|
|
285
|
-
|
|
286
|
-
8.2 Managed Usage Plans
|
|
287
|
-
For clients preferring single monthly invoices:
|
|
288
|
-
Starter Plan
|
|
289
|
-
€399/month per instance
|
|
290
|
-
10M standard text tokens/month
|
|
291
|
-
2M embedding tokens/month
|
|
292
|
-
Medium Plan
|
|
293
|
-
€899/month per instance
|
|
294
|
-
30M standard text tokens/month
|
|
295
|
-
6M embedding tokens/month
|
|
296
|
-
Heavy Plan
|
|
297
|
-
€1,999/month per instance
|
|
298
|
-
80M standard text tokens/month
|
|
299
|
-
15M embedding tokens/month
|
|
300
|
-
|
|
301
|
-
8.3 Overage & Enterprise Options
|
|
302
|
-
Usage beyond allowance billed at provider pass-through rates plus platform handling fee
|
|
303
|
-
Pre-purchased top-up credits available
|
|
304
|
-
Enterprise clients can request custom caps, allow-lists, and spend limits
|
|
305
|
-
|
|
306
|
-
|
|
307
|
-
9. Target Market & Value Proposition
|
|
308
|
-
9.1 Ideal Customers
|
|
309
|
-
Agencies delivering AI solutions to multiple clients
|
|
310
|
-
Internal engineering teams building AI platforms for business units
|
|
311
|
-
AI developers wanting reusable platform foundations
|
|
312
|
-
Teams needing built-in admin tooling, pages, and knowledge ingestion
|
|
313
|
-
|
|
314
|
-
9.2 Problems Solved
|
|
315
|
-
Eliminates repeated rebuilding of authentication, admin tooling, storage, and UI scaffolding
|
|
316
|
-
Makes knowledge base ingestion a product feature rather than custom project
|
|
317
|
-
Maintains per-client deployment isolation for security and operational simplicity
|
|
318
|
-
Provides integrated page system for marketing/product pages
|
|
319
|
-
Includes ML Lab for analytics without separate environment
|
|
320
|
-
|
|
321
|
-
9.3 Key Outcomes
|
|
322
|
-
Faster time-to-demo and time-to-production
|
|
323
|
-
Clear governance with roles, audits, and secrets management
|
|
324
|
-
Lower operational risk through per-client isolation
|
|
325
|
-
Better cost control via model profiles and routing
|
|
326
|
-
Extensible platform for custom connectors and pages
|
|
327
|
-
|
|
328
|
-
|
|
329
|
-
|
|
330
|
-
10. Implementation Methodology
|
|
331
|
-
10.1 Implementation Playbook
|
|
332
|
-
Phase 1: Discovery
|
|
333
|
-
Define client use cases (support, policy Q&A, analytics, internal tooling)
|
|
334
|
-
Confirm data sources for ingestion
|
|
335
|
-
Agree hosting model (client-managed vs SyntaxMatrix-managed)
|
|
336
|
-
Define access model (roles, SSO requirements, network restrictions)
|
|
337
|
-
|
|
338
|
-
Phase 2: Provisioning
|
|
339
|
-
Create per-client deployment and instance directory
|
|
340
|
-
Initialize databases and admin accounts
|
|
341
|
-
Configure model profiles
|
|
342
|
-
Upload core system documents
|
|
343
|
-
Generate and publish initial pages
|
|
344
|
-
|
|
345
|
-
Phase 3: Production Hardening
|
|
346
|
-
Set spend limits and allow-lists for providers
|
|
347
|
-
Add monitoring and error reporting
|
|
348
|
-
Implement backup strategy for SQLite, server DBs, and uploads
|
|
349
|
-
Define change management and release cadence
|
|
350
|
-
|
|
351
|
-
10.2 Demo Script
|
|
352
|
-
Log in as admin, show role management and secrets
|
|
353
|
-
Upload 2-3 PDFs, demonstrate ingestion completion
|
|
354
|
-
Ask assistant questions showing retrieved answers
|
|
355
|
-
Generate new page in Page Studio, patch/publish it
|
|
356
|
-
Upload dataset and run Machine Learning Lab task to show explainable and downloadable report: tables/plots, generated code for said tasks, and output summary.
|
|
357
|
-
|
|
358
|
-
|
|
359
|
-
11. Competitive Landscape
|
|
360
|
-
11.1 Pricing Reference Points (Late Dec 2025)
|
|
361
|
-
Dify Cloud: Professional $59-$159 per workspace/month
|
|
362
|
-
Flowise Cloud: Starter $35, Pro $65/month
|
|
363
|
-
Botpress: Plus $89, Team $495/month (+ AI spend)
|
|
364
|
-
Dust: Pro €29 per user/month
|
|
365
|
-
LangSmith: Plus $39 per seat/month
|
|
366
|
-
Stack AI: Starter $199, Team $899/month
|
|
367
|
-
|
|
368
|
-
11.2 SyntaxMatrix Differentiation
|
|
369
|
-
Per-instance licensing aligns with per-client deployment reality
|
|
370
|
-
BYOK model keeps model spend under client's provider billing
|
|
371
|
-
Managed usage plans bundle platform fee with usage allowance
|
|
372
|
-
Comprehensive platform (not just chatbot) with Admin Panel, Page Studio, ML Lab
|
|
373
|
-
|
|
374
|
-
|
|
375
|
-
12. Brand & Messaging
|
|
376
|
-
12.1 Core Messages
|
|
377
|
-
"Provision a client-ready AI platform in days, not weeks"
|
|
378
|
-
"Built-in Admin Panel for users, secrets, pages, and knowledge base ingestion"
|
|
379
|
-
"Page Studio: generate and publish pages from templates with AI assistance"
|
|
380
|
-
"ML Lab: guided dataset analysis inside the same platform"
|
|
381
|
-
"Model profiles provide cost control and specialist outputs"
|
|
382
|
-
|
|
383
|
-
12.2 Short Boilerplate
|
|
384
|
-
"SyntaxMatrix is an Irish AI engineering company. SyntaxMatrix helps teams ship client-ready AI platforms with a framework that includes an assistant, knowledge base ingestion, Page Studio, and an ML Lab."
|
|
385
|
-
|
|
386
|
-
|
|
387
|
-
12.3 Brand Positioning
|
|
388
|
-
Positioned as an AI engineering company building deployable AI platform framework, focusing on:
|
|
389
|
-
Delivery speed and repeatability
|
|
390
|
-
Operational controls
|
|
391
|
-
Adaptability to any industry
|
|
392
|
-
|
|
393
|
-
13. Operating Information
|
|
394
|
-
13.1 Weekly Cadence
|
|
395
|
-
Monday: Priorities, risk review, customer escalations
|
|
396
|
-
Mid-week: Engineering planning and QA sign-off for releases
|
|
397
|
-
Friday: Demos, customer feedback review, roadmap updates
|
|
398
|
-
|
|
399
|
-
13.2 Quality Gates
|
|
400
|
-
Changes reviewed and tested before release
|
|
401
|
-
Security-sensitive changes require compliance sign-off
|
|
402
|
-
Provisioning templates/scripts versioned and tested like product code
|
|
403
|
-
|
|
404
|
-
13.3 Support Structure
|
|
405
|
-
Basic support included with all plans
|
|
406
|
-
Premium support options available
|
|
407
|
-
Uptime targets for managed hosting (TBC)
|
|
408
|
-
|
|
409
|
-
|
|
410
|
-
14. Technical Glossary
|
|
411
|
-
Agency/Profile: Named configuration for provider + model + purpose
|
|
412
|
-
RAG: Retrieval Augmented Generation - answering with retrieved context
|
|
413
|
-
SMIV: SyntaxMatrix In-memory Vectorstore (transient)
|
|
414
|
-
SMPV: SyntaxMatrix Persistent Vectorstore (SQLite embeddings, Server DB)
|
|
415
|
-
Chunk: Section of extracted document text stored for retrieval
|
|
416
|
-
ML Lab: Dataset analysis environment with code generation and execution
|
|
417
|
-
Page Studio: Page generation and publishing workflow
|
|
418
|
-
MoE: Mixture-of-Experts - using different model profiles for different tasks
|
|
419
1250
|
|
|
1251
|
+
SMXAI_GALLERY_PAGE_INSTRUCTIONS = """
|
|
1252
|
+
You are generating a GALLERY page. This page must behave like a true photo/screenshot gallery.
|
|
1253
|
+
|
|
1254
|
+
ABSOLUTE REQUIREMENTS
|
|
1255
|
+
1) The page plan MUST include a section with:
|
|
1256
|
+
- type: "gallery"
|
|
1257
|
+
- id: "sec_gallery" (or similar)
|
|
1258
|
+
2) The gallery section MUST contain 6–9 items where EACH item is a true image tile:
|
|
1259
|
+
- item.type MUST be "image" (NOT "card")
|
|
1260
|
+
- Use short titles (2–5 words max) and very short captions (0–1 sentence).
|
|
1261
|
+
- Avoid long paragraphs in the gallery; do NOT make it look like a features section.
|
|
1262
|
+
|
|
1263
|
+
GALLERY ITEM SCHEMA (use this exactly)
|
|
1264
|
+
Each gallery item MUST look like:
|
|
1265
|
+
{
|
|
1266
|
+
"id": "g1",
|
|
1267
|
+
"type": "image",
|
|
1268
|
+
"title": "Admin Panel",
|
|
1269
|
+
"text": "Pages, uploads, audit trail.",
|
|
1270
|
+
"imgQuery": "admin panel dashboard ui dark theme",
|
|
1271
|
+
"needsImage": true,
|
|
1272
|
+
"imageUrl": "",
|
|
1273
|
+
"thumbUrl": "",
|
|
1274
|
+
}
|
|
1275
|
+
|
|
1276
|
+
NOTES:
|
|
1277
|
+
- imageUrl/thumbUrl can be empty at planning time; the system will fill them later from imgQuery.
|
|
1278
|
+
- If a thumbnail exists, thumbUrl should point to it; imageUrl should point to the full image.
|
|
1279
|
+
- The gallery rail should be primarily visual. Captions are optional and must be short.
|
|
1280
|
+
|
|
1281
|
+
DESIGN INTENT
|
|
1282
|
+
- Gallery section = image-first browsing (tiles, click opens lightbox).
|
|
1283
|
+
- If you need explanatory content, put it in separate sections (richtext/features/cta) OUTSIDE the gallery.
|
|
1284
|
+
- Do NOT place "card" items inside the gallery section unless explicitly requested (default: none).
|
|
1285
|
+
|
|
1286
|
+
PAGE STRUCTURE (recommended)
|
|
1287
|
+
- hero (clear title + one sentence)
|
|
1288
|
+
- gallery (the rail of image tiles; 6–9 items)
|
|
1289
|
+
- richtext or testimonials (optional, short)
|
|
1290
|
+
- cta (contact / request demo)
|
|
1291
|
+
|
|
1292
|
+
TONE
|
|
1293
|
+
- Enterprise AI product showcase, clean and concise.
|
|
420
1294
|
"""
|
|
421
1295
|
|
|
422
|
-
|
|
1296
|
+
|
|
1297
|
+
SMXAI_CAREERS_PAGE_INSTRUCTIONS = """
|
|
1298
|
+
You are generating a CAREERS page for SyntaxMatrix.
|
|
1299
|
+
|
|
1300
|
+
GOAL
|
|
1301
|
+
Create a careers landing page that:
|
|
1302
|
+
- communicates mission + culture clearly
|
|
1303
|
+
- lists open roles in a structured way
|
|
1304
|
+
- explains hiring process and expectations
|
|
1305
|
+
- provides a clear application CTA
|
|
1306
|
+
- stays concise, skimmable, and professional (enterprise AI company tone)
|
|
1307
|
+
|
|
1308
|
+
ABSOLUTE REQUIREMENTS
|
|
1309
|
+
1) The plan MUST include a hero section (type: "hero") with:
|
|
1310
|
+
- a clear headline about careers at SyntaxMatrix
|
|
1311
|
+
- a short subheading (1–2 sentences) that communicates mission and what candidates can expect
|
|
1312
|
+
- a primary CTA such as "Apply now" / "Email your CV"
|
|
1313
|
+
- optional secondary CTA "View open roles"
|
|
1314
|
+
|
|
1315
|
+
2) The plan MUST include an "Open Roles" section.
|
|
1316
|
+
Use either:
|
|
1317
|
+
- type: "features" (recommended), OR
|
|
1318
|
+
- type: "richtext" if you need richer formatting.
|
|
1319
|
+
Each role must be presented as a compact card-like entry with:
|
|
1320
|
+
- Role Title
|
|
1321
|
+
- Location/Remote (e.g., Ireland / Remote / Hybrid Dublin)
|
|
1322
|
+
- Type (Full-time / Contract / Internship)
|
|
1323
|
+
- Short summary (max 2 sentences)
|
|
1324
|
+
- Key skills (4–6 bullet-style phrases)
|
|
1325
|
+
- An "Apply" callout (email or link placeholder)
|
|
1326
|
+
|
|
1327
|
+
3) The plan MUST include a hiring process section that is clear and realistic.
|
|
1328
|
+
Use type: "richtext" or "features" with 4–6 steps:
|
|
1329
|
+
- Apply
|
|
1330
|
+
- Screening
|
|
1331
|
+
- Technical assessment (practical, small)
|
|
1332
|
+
- Interview(s)
|
|
1333
|
+
- Offer
|
|
1334
|
+
- Onboarding
|
|
1335
|
+
|
|
1336
|
+
4) The plan MUST include a FAQ section (type: "faq") with at least 6 FAQs:
|
|
1337
|
+
Include: remote policy, visa sponsorship (if unknown say “case-by-case”), interview steps,
|
|
1338
|
+
expected stack, timeline, compensation transparency approach, and what makes a strong application.
|
|
1339
|
+
|
|
1340
|
+
5) The plan MUST include a final CTA section (type: "cta") with:
|
|
1341
|
+
- a direct instruction to apply (email/link placeholder)
|
|
1342
|
+
- what to include (CV, links, short note, portfolio/GitHub)
|
|
1343
|
+
- response time expectation (e.g., “we aim to respond within X business days”)
|
|
1344
|
+
|
|
1345
|
+
CONTENT CONSTRAINTS
|
|
1346
|
+
- Do NOT invent named employees or fake testimonials.
|
|
1347
|
+
- Do NOT claim benefits you cannot guarantee (health insurance, pension, etc.). If unsure, phrase as “where applicable” or omit.
|
|
1348
|
+
- Avoid exaggerated claims. Keep language grounded and specific.
|
|
1349
|
+
- Avoid long paragraphs. Prefer short blocks, lists, and scannable structure.
|
|
1350
|
+
- Keep total page copy “tight”: aim for clarity over volume.
|
|
1351
|
+
|
|
1352
|
+
STYLE
|
|
1353
|
+
- Enterprise AI engineering vibe: confident, precise, practical.
|
|
1354
|
+
- Emphasise that SyntaxMatrix is an AI algorithm design company and a framework builder (RAG systems, multi-agent workflows, evaluation, deployments).
|
|
1355
|
+
- Mention core tech themes appropriately: Python, Flask, Dash, vector stores, RAG, eval tooling, cloud deployments, MLOps. Do not overspecify if not necessary.
|
|
1356
|
+
|
|
1357
|
+
RECOMMENDED PAGE STRUCTURE (sections)
|
|
1358
|
+
1) hero
|
|
1359
|
+
2) richtext: "Why work with us" (mission, values, what you’ll build)
|
|
1360
|
+
3) features: "Open roles" (6–10 role cards max; if fewer roles, show 3–6)
|
|
1361
|
+
4) richtext/features: "Hiring process"
|
|
1362
|
+
5) faq
|
|
1363
|
+
6) cta
|
|
1364
|
+
|
|
1365
|
+
OPEN ROLES (DEFAULT SET)
|
|
1366
|
+
If no specific roles were provided, include a sensible starter list (edit titles to fit page length):
|
|
1367
|
+
- AI/ML Engineer (RAG + agents)
|
|
1368
|
+
- Full-stack Engineer (Flask/Dash + UI)
|
|
1369
|
+
- MLOps / Platform Engineer (deployments, CI/CD)
|
|
1370
|
+
- Technical Writer / Developer Advocate (docs, examples, workshops)
|
|
1371
|
+
- Intern / Graduate (AI Engineering)
|
|
1372
|
+
|
|
1373
|
+
ROLE CARD TEMPLATE (features item shape)
|
|
1374
|
+
Each role in the "Open roles" section should be an item like:
|
|
1375
|
+
{
|
|
1376
|
+
"id": "role_1",
|
|
1377
|
+
"type": "card",
|
|
1378
|
+
"title": "AI/ML Engineer (RAG + Agents)",
|
|
1379
|
+
"text": "Build production RAG pipelines and deterministic multi-agent workflows. Remote/Hybrid • Full-time/Contract.\nSkills: Python, vector search, evaluation, prompt/tool orchestration, deployments.\nApply: careers@<your-domain> (placeholder)"
|
|
1380
|
+
}
|
|
1381
|
+
|
|
1382
|
+
FAQ SUGGESTED QUESTIONS (use or adapt)
|
|
1383
|
+
- Do you offer remote work?
|
|
1384
|
+
- What does the interview process look like?
|
|
1385
|
+
- What tech stack do you use day-to-day?
|
|
1386
|
+
- Do you sponsor visas?
|
|
1387
|
+
- What should I include in my application?
|
|
1388
|
+
- How quickly will I hear back?
|
|
1389
|
+
- Can I apply if I’m early-career?
|
|
1390
|
+
- Do you take contractors?
|
|
1391
|
+
|
|
1392
|
+
FINAL CTA COPY REQUIREMENTS
|
|
1393
|
+
Include:
|
|
1394
|
+
- email placeholder and/or application link placeholder
|
|
1395
|
+
- request: CV + links (GitHub/LinkedIn/portfolio) + short note
|
|
1396
|
+
- note: “If you’ve built RAG systems, agent workflows, or evaluation tooling, include a brief write-up.”
|
|
1397
|
+
|
|
1398
|
+
OUTPUT QUALITY CHECK
|
|
1399
|
+
Before finalising, ensure:
|
|
1400
|
+
- "Open roles" exists and is clearly labelled.
|
|
1401
|
+
- Hiring process is present and actionable.
|
|
1402
|
+
- FAQ has 6+ items.
|
|
1403
|
+
- CTA is explicit and contains application instructions.
|
|
1404
|
+
"""
|
|
1405
|
+
|
|
1406
|
+
|
|
1407
|
+
SMXAI_BLOG_PAGE_INSTRUCTIONS = """
|
|
1408
|
+
## 3.1 Blog index page structure
|
|
1409
|
+
1) Hero
|
|
1410
|
+
2) Featured post
|
|
1411
|
+
3) Post grid
|
|
1412
|
+
4) Tag filter + search
|
|
1413
|
+
5) CTA (optional newsletter)
|
|
1414
|
+
|
|
1415
|
+
Post cards:
|
|
1416
|
+
- Title (2 lines)
|
|
1417
|
+
- Excerpt (2–3 lines)
|
|
1418
|
+
- Date + tag
|
|
1419
|
+
- “Read more”
|
|
1420
|
+
|
|
1421
|
+
## 3.2 Blog post page structure
|
|
1422
|
+
- Title + metadata
|
|
1423
|
+
- Optional TOC from H2/H3
|
|
1424
|
+
- Body with callouts
|
|
1425
|
+
- CTA footer
|
|
1426
|
+
|
|
1427
|
+
---
|
|
1428
|
+
|
|
1429
|
+
# 4) Matching rules (template selection)
|
|
1430
|
+
|
|
1431
|
+
- “services”, “solutions”, “packages”, “pricing”, “engagement”
|
|
1432
|
+
→ Services Page
|
|
1433
|
+
|
|
1434
|
+
- “gallery”, “photos”, “portfolio”, “screenshots”, “showcase”
|
|
1435
|
+
→ Gallery Page (horizontal + lightbox)
|
|
1436
|
+
|
|
1437
|
+
- “blog”, “articles”, “updates”, “news”, “release notes”
|
|
1438
|
+
→ Blog Page
|
|
1439
|
+
|
|
1440
|
+
"""
|
|
1441
|
+
|
|
1442
|
+
|
|
1443
|
+
SMXAI_NEW_PAGE_INSTRUCTIONS_DEFAULT = f"""
|
|
423
1444
|
0· Parse the Website Description (MANDATORY):\n{SMXAI_WEBSITE_DESCRIPTION}\n\n
|
|
424
1445
|
1. Input always contains:
|
|
425
1446
|
• website_description - plain-text overview of the site/company (mission, goals, audience, visual style, etc.).
|
|
@@ -463,7 +1484,7 @@ SMXAI_PAGE_INSTRUCTIONS = f"""
|
|
|
463
1484
|
o Parse website_description and page_title per Steps 0–6.
|
|
464
1485
|
o Compose the entire HTML document as a single triple-quoted Python string (page_html = ''' … ''').
|
|
465
1486
|
o Return that string (return html).
|
|
466
|
-
|
|
1487
|
+
requirement.
|
|
467
1488
|
iii. Function docstring
|
|
468
1489
|
'''
|
|
469
1490
|
Generate a fully responsive, animated, single-file web page aligned with the
|
|
@@ -483,4 +1504,38 @@ SMXAI_PAGE_INSTRUCTIONS = f"""
|
|
|
483
1504
|
• No duplicate header/footer.
|
|
484
1505
|
• All identifiers safely namespaced.
|
|
485
1506
|
• Return only the HTML text—no commentary or extra files.
|
|
486
|
-
"""
|
|
1507
|
+
"""
|
|
1508
|
+
|
|
1509
|
+
|
|
1510
|
+
def get_page_instructions(page_slug: str = "", page_title: str = "") -> str:
|
|
1511
|
+
"""
|
|
1512
|
+
Returns the correct page-type instruction block based on the requested page slug/title.
|
|
1513
|
+
This is used to override the generic default prompt during AI page generation.
|
|
1514
|
+
"""
|
|
1515
|
+
key = f"{page_slug or ''} {page_title or ''}".strip().lower()
|
|
1516
|
+
|
|
1517
|
+
# Home page
|
|
1518
|
+
if any(w in key for w in ("home", "home-page", "homepage", "landing", "landing-page")):
|
|
1519
|
+
return SMXAI_HOME_PAGE_INSTRUCTIONS
|
|
1520
|
+
|
|
1521
|
+
# About page
|
|
1522
|
+
if any(w in key for w in ("about", "about-us", "who-we-are", "company", "our-story", "team")):
|
|
1523
|
+
return SMXAI_ABOUT_PAGE_INSTRUCTIONS
|
|
1524
|
+
|
|
1525
|
+
# Services page
|
|
1526
|
+
if any(w in key for w in ("services", "solutions", "packages", "pricing", "engagement")):
|
|
1527
|
+
return SMXAI_SERVICES_PAGE_INSTRUCTIONS
|
|
1528
|
+
|
|
1529
|
+
# Gallery page
|
|
1530
|
+
if any(w in key for w in ("gallery", "photos", "portfolio", "screenshots", "showcase")):
|
|
1531
|
+
return SMXAI_GALLERY_PAGE_INSTRUCTIONS
|
|
1532
|
+
|
|
1533
|
+
if any(w in key for w in ("careers", "jobs", "pricing", "contact", "contact-us", "docs", "documentation", "join", "join-us")):
|
|
1534
|
+
return SMXAI_CAREERS_PAGE_INSTRUCTIONS
|
|
1535
|
+
|
|
1536
|
+
# Blog page
|
|
1537
|
+
if any(w in key for w in ("blog", "articles", "updates", "news", "release-notes")):
|
|
1538
|
+
return SMXAI_BLOG_PAGE_INSTRUCTIONS
|
|
1539
|
+
|
|
1540
|
+
# Fallback
|
|
1541
|
+
return SMXAI_NEW_PAGE_INSTRUCTIONS_DEFAULT
|