How GCSI works

Live

Accounts, sign-in and profiles

Verified member accounts with privacy-controlled profiles, context-preserving authentication and member-visible session security.

#

1. Create an account with email and a profile ID, or continue with a verified Google identity.
2. Email sign-up requires a six-digit verification step before the account becomes active. Verification codes are short-lived, single-use and are not displayed in administrator logs.
3. When a visitor starts a sign-in-required action from a recipe, GCSI preserves the safe internal return destination and brings the person back to that recipe after authentication instead of sending them to an unrelated dashboard page.
4. Profile visibility is private by default and can be changed in Account settings.
5. Password recovery and important account-security messages use the sign-in email and cannot be disabled when required to operate or protect the account.
6. Account settings show the active session generation for this account using a protected session fingerprint and a broad browser/device label. Raw PHP session identifiers and IP addresses are not stored in the member session registry.
7. A member can choose Sign out other sessions. GCSI invalidates every other current or older account session while keeping the device used for the security action signed in.

Live

Recipe contribution and publication

Contributor-owned submissions with administrator publication authority and revision feedback.

#

1. A GCSI administrator first approves recipe-submission access for an eligible member.
2. The contributor opens Recipes → Submit a recipe and enters the recipe, safety notes, nutrition information and original photographs.
3. The submitted recipe remains private while it is reviewed.
4. An administrator can publish it, request specific changes, reject it, or keep it private.
5. Requested-change feedback remains attached to the recipe management record so the contributor can revise it without relying on an email alone.
6. After publication, a contributor edit returns the recipe to private review before the revised version can be public again.
7. Recipe submission uses a guided section navigator so contributors can see where they are and move directly between dish basics, timing, method, gluten safety, nutrition and photographs.
8. Draft recovery runs quietly while a contributor works. Recovery information is surfaced when it is actually useful, such as after an interrupted or invalid submission, rather than occupying permanent form space.
9. Nutrition information remains visible when a contributor reaches that section. Europe and United States previews use the same stored recipe values but show the terminology and units appropriate to each public presentation.

Live

Editing, hiding and deleting recipes

Clear ownership controls with recoverable removal rather than silent destruction.

#

1. A recipe contributor can open their own recipe management screen to edit or delete their recipe.
2. Administrators use a compact Manage control on the public recipe page and the full controls inside the administration editor.
3. Hide/archive removes a recipe from public view while retaining its record for possible restoration.
4. Delete is a soft-delete: the public recipe is removed, the action is audited, and the record can be restored administratively if deletion was accidental.
5. Deleting or hiding a recipe does not silently erase contributor attribution or audit history.

Live

Recipe comments and reports

Member participation with moderation and a private reporting route.

#

1. Signed-in members can submit recipe comments and permitted photographs.
2. Comments are moderated before becoming public.
3. A member can privately report a recipe concern to GCSI.
4. The reporter can receive status updates when a report is investigated, resolved, dismissed or reopened.
5. A private report is not automatically disclosed to the recipe author.

Live

Knowledge Hub contributions

Referenced improvements are reviewed before changing public guidance.

#

1. Members can propose supported corrections or edits where contribution tools are enabled.
2. The public article remains unchanged while the contribution is reviewed.
3. Reviewers record a decision and the contribution history remains attributable.
4. Accepted changes become part of the public version only after the required human review.

Live

Notifications, email and newsletter

Account-connected updates with member-controlled categories/frequency, deterministic priority and grouping of related activity.

#

1. Essential account messages include verification, password recovery, important security/privacy notices and the one-time welcome message.
2. Activity notifications cover eligible contribution, recipe, community, research, Academy, restaurant and platform events.
3. Members choose whether optional activity email arrives as events happen, weekly, monthly or not by email at all.
4. Newsletter consent is separate, off by default and never required for an account.
5. The protected delivery worker processes queued activity, essential and newsletter email independently of page requests, with retry controls and durable event keys designed to prevent duplicate business actions.
6. Hard-bounce, complaint and administrator suppression records can stop further delivery without exposing raw recipient addresses in the suppression registry. A soft bounce is recorded but does not automatically become a permanent suppression.
7. In-app notifications remain connected to the member account and can be read independently of email delivery.
8. The in-app notification centre orders action-required activity such as review assignments or requested changes ahead of routine account activity, followed by important decisions and then normal activity.
9. Related notifications about the same record are grouped into one logical update. Opening or marking that group read updates the underlying notification records together.
10. Priority changes ordering and presentation only. It never bypasses a member’s category or email-frequency preferences and does not convert optional activity into essential account email.

Live

Privacy and analytics choice

Google Analytics is consent-gated and limited to eligible public pages.

#

1. GCSI does not load the Google Analytics tag on an eligible public page until the visitor chooses to allow analytics, unless that device already holds a prior allow choice.
2. Choosing Only necessary keeps analytics off. The visitor can change the choice later from Cookie settings in the public-site footer.
3. The analytics integration uses measurement ID G-QB2ZH9G6TD. Advertising storage, ad user data and ad personalisation are disabled in the GCSI integration.
4. Administration, authentication/recovery, dashboard, settings, profile management, recipe submission, saved recipes and private recipe-management surfaces are excluded from this analytics integration.
5. The analytics choice is stored on the visitor’s device so the preference can be applied on later eligible public pages.

Live · administrator only

Communication delivery, previews and audit

Administrators can inspect delivery, preview branded templates and manage suppression without exposing reusable account-security credentials.

#

1. The delivery-health view shows configuration readiness, queue state and recent worker/delivery outcomes without displaying credentials or recipient lists.
2. Email & notification history distinguishes verification, password reset, welcome, activity and newsletter records and shows sent, failed, pending, retry or skipped states where available.
3. The Communications studio can render the same branded HTML template used for production delivery and can send a marked test only to the currently signed-in administrator’s own verified account.
4. Email suppressions record protected recipient identifiers for hard-bounce, complaint or manual-suppression events. Provider feedback requires a separately signed webhook integration before automatic callbacks become active.
5. Recipient email addresses are masked in administration history; known members may be identified by their account name/profile ID.
6. Verification codes and password-reset tokens are never displayed in communication history. Account codes are stored as one-way HMAC values rather than reusable plaintext.
7. A “sent” delivery state means the configured mail transport accepted the message; it does not prove that a person opened or read the email.

Live

Review, permissions, audit and recoverability

Important editorial and administrative actions are role-controlled, recorded and designed to be recoverable where appropriate.

#

1. Publication decisions remain human-controlled.
2. Role checks restrict administration and editorial actions; an administration Roles & permissions matrix documents the current production authority model.
3. Conditional permissions such as recipe contribution, recipe ownership and assigned review still require the underlying capability or assignment in addition to an account role.
4. Audit records capture relevant actions with actor, time and context.
5. Observability pages are designed to inspect system state rather than modify application data simply by being viewed.
6. Notification delivery is decoupled from the underlying content action, so an email failure does not repeat or roll back a recipe or editorial decision.

Live

Public service status and incident history

A public, dependency-light record of confirmed GCSI service incidents without exposing private operational diagnostics.

#

1. Anyone can open /status to see confirmed incidents affecting Website & public content, Member accounts, or Email & notifications.
2. The public status page is deliberately separate from GCSI’s private operational-health dashboard. Internal alerts and diagnostic thresholds do not automatically become public outage claims.
3. An administrator first creates a private incident draft, checks the impact and public wording, then explicitly publishes the incident when the facts are sufficiently confirmed.
4. Published incidents receive timestamped Investigating, Identified, Monitoring and Resolved updates. Resolving an incident moves it into the public history rather than silently deleting it.
5. The absence of a published incident means no confirmed incident is currently published; it is not a promise of uninterrupted service or exhaustive monitoring.
6. The public incident ledger is file-backed and does not require the application database to render. If that ledger cannot be read, the page shows Status information temporarily unavailable rather than a green state.