DAWN — the Dynamic AmadeusWeb Network — is the product and service ecosystem built and operated by Prometheus, the IT Product and Services wing of AmadeusWeb. For 26 years, I have built systems across the spectrum, from hobbyist projects to enterprise-grade environments. That experience informs DAWN's practical, human-scale approach to technology. AmadeusWeb Spring is its publishing and site-building foundation, combining open web and file-management technologies with the AmadeusWeb codebase.

DAWN gives customers a coherent path from discovery to an owned web presence, federation, and the relationship and operational systems behind their work. The layers below set out the product direction and roadmap; they distinguish the integrated vision from capabilities that are still to be delivered.

Our Unique 4 Stage Process

1. Marketing — Make the mission understandable and discoverable
2. Federation — Connect independent homes without erasing them
3. Security — Protect people, content and operations by design
4. CRM / ERP — Manage relationships and deliver the work

Product progression

1. Establish the home: clarify the mission and offer; create the member's site, key pages and enquiry path.
2. Prove the relationship workflow: make enquiries, consent, follow-up and service delivery usable for one organisation.
3. Connect members deliberately: add directories, referrals and shared listings with opt-in participation, provenance and exit paths.
4. Harden and integrate: strengthen operational security, backups, access reviews and data export; connect CRM/ERP workflows to specialist tools where needed.
5. Learn and improve: use member feedback and transparent, privacy-conscious service measures to prioritise the next capabilities.

Prometheus brings these layers together as an integrated product and services practice. We help members communicate clearly, establish their own web presence, collaborate through federation, protect their information, and run customer and operational workflows with appropriate tools. DAWN is measured not by how much data or attention it centralises, but by how well it enables people to sustain useful, trustworthy work together.

1. Marketing — Make the mission understandable and discoverable

Marketing in DAWN is not just promotion. It is the clear presentation of who an organisation is, what it offers, whom it serves, and how someone can take a meaningful next step.

• Positioning: Explain DAWN as an alternative to fragmented, attention-driven platforms: a web presence that an individual or organisation can shape and retain, with connections built around purpose rather than a single algorithmic feed.
• Audience and offer: Help each member describe its audiences, products, services, initiatives and values in its own language. Prometheus delivers the practical services that bring this into operation: discovery, site setup, content strategy, hosting and ongoing technical support.
• Owned publishing: Use a member's site as the canonical source for its pages, articles, events and resources. Social channels and campaigns can point back to this home instead of becoming the only place the work exists.
• Journey and measurement: Provide clear calls to action—enquire, subscribe, join, volunteer, book or buy—and measure useful outcomes such as qualified enquiries and completed actions. Keep measurement proportionate, transparent and privacy-conscious; do not make engagement-maximising surveillance a product requirement.
• Trust: Make authorship, contact details, service terms, pricing where applicable, and the organisation's intentions easy to find. Marketing promises should match what the network can actually deliver.

Outcome: a prospective member can understand the offer, find the right information, and choose a next step without surrendering ownership of its public identity to a third-party platform.

2. Federation — Connect independent homes without erasing them

Federation is the network layer: separate people and organisations keep their own sites, identities and governance while choosing to make selected connections with one another. It is not a requirement to merge everyone into one portal or central database.

• Independent nodes: Each member has a durable web home and remains responsible for its own published content, audience relationships and local policies.
• Interoperable connections: Establish documented, versioned ways to link or exchange intentionally shared information—such as public profiles, events, service listings, referrals and directory entries. Prefer open web standards and portable formats; make participation possible without requiring every member to use every DAWN service.
• Consent and boundaries: Let each node decide what is public, shared with the federation, or private. Show the source of shared information and provide a clear way to correct or withdraw it.
• Discovery and referrals: Offer a network directory and mission-oriented pathways that help people find relevant members. A referral should preserve context and consent rather than silently exporting a contact list.
• Governance: Publish federation rules, responsibilities, dispute routes and exit procedures. Keep technical participation distinct from endorsement: being connected to DAWN should not imply agreement with every member or central authority.
• Resilience: Avoid a single point of failure where practical. Back up data, document migration and export paths, and design for members to retain useful standalone sites if a shared service changes or becomes unavailable.

Outcome: a network that gains value from connection while preserving local autonomy, clear provenance and the option to leave.

3. Security — Protect people, content and operations by design

Security is a foundation across publishing, federation and business operations, not a feature bolted on at the end. The goal is to reduce avoidable risk while keeping the system understandable to the people who operate it.

• Identity and access: Use individual accounts, strong authentication, least-privilege roles and prompt removal of access when responsibilities end. Separate administrative access from ordinary publishing.
• Data minimisation: Collect only the information needed for a stated purpose. Classify public, shared, internal and sensitive data; do not put sensitive records in public content folders or federation feeds.
• Safe operation: Keep software and dependencies maintained; protect administrative interfaces; use encrypted connections; manage secrets outside public files and repositories; and maintain tested, access-controlled backups.
• Privacy and consent: Explain what data is collected, where it is stored, who can access it, how long it is retained and how a person can request correction or deletion. Apply retention rules to enquiries and customer records.
• Accountability and response: Keep proportionate audit trails for important administrative changes, define who responds to incidents, and provide a clear reporting channel. Document recovery steps and review them after incidents or significant changes.
• Secure federation: Authenticate service-to-service exchanges where needed, validate incoming data, limit scopes and permissions, and make revocation possible. Federation must not turn a member's private records into network-wide data.

Outcome: members can understand their responsibilities, control access to their information, and recover from common operational failures.

4. CRM / ERP — Manage relationships and deliver the work

CRM and ERP capabilities should support the missions and businesses on DAWN, with a deliberate boundary between a member's private operations and public network content. Start with simple, exportable workflows; add complexity only when members need it.

• CRM (relationships): Track enquiries, consented contacts, conversations, referrals, opportunities, service agreements and follow-ups. Record where a contact came from and what communications they agreed to receive.
• ERP (operations): Support the operational records a participating organisation needs, such as service delivery, projects, tasks, suppliers, inventory where relevant, invoices, payments and reporting. Treat accounting, tax and employment requirements as jurisdiction-specific integrations or workflows, not universal assumptions.
• Connected workflow: A public page or campaign can lead to an enquiry; the enquiry can become a consented CRM record; an accepted engagement can create operational work; delivery and finance records can support reporting. Each transition should be visible, permissioned and traceable.
• Member-owned records: Keep records scoped to the organisation that collected them. Share only the minimum information required for a specific referral or transaction, with an appropriate basis and clear consent.
• Integration and portability: Prefer documented APIs and standard exports over lock-in. Allow members to export their records and use specialist accounting, payment, email or scheduling tools when those are a better fit.
• Practical entry point: Begin with an enquiry inbox, a small contact pipeline, follow-up reminders and a basic service/project register. Validate demand before building a comprehensive suite.

Outcome: marketing, customer care and delivery form a coherent workflow without turning the federation into a central owner of every member's business data.