EVE Glyph Reference Assessment Service

What this is

A worked instance of the EVE Glyph design protocol vectoring outward to a new substrate: enterprise architecture assessment. Any enterprise user can submit an AI-related solution architecture and have it assessed against the EVE Glyph reference model, with the assessment subject to live streams and public-domain event monitoring.

Per Pattern 6 in game/design/observed-operator-patterns.md, this is extended vectoring, not new methodology. The lattice already specifies the protocol; this directory documents how the protocol operates when applied to enterprise architecture submissions. If the protocol changes as a result of running this service over time, the lattice gets the change. The service itself stays here.

What an enterprise submission gets

An EVE Glyph reference assessment of a submitted AI-related solution architecture. The assessment is structured against the methodology and produces a quantified reading the submitter can act on:

Cognitive fitness reading (Methodology 13). Where in the architecture is the human-in-the-loop, and is that human positioned to pass Test A through Test H against this architecture in operation?
Wobble reading (Methodology 12). Where does the architecture run faster than the operators inside it can dampen wobble? Where is speed the friend; where is speed the failure mode?
Lock-in disclosure (Methodology 14). Enumeration of every lock-in the architecture commits to: institutional, commercial, personal-bias, psychological, success. All forms of lock-in are darkness; the assessment makes them visible.
Start-position reading (Methodology 15). Does the architecture have a defined start position for its operators? Can it be reset and restarted? Does it carry the universal start-position structure across its biological, electronic, and methodological subsystems?
Monitor escalation maturity (Methodology 16). Does the architecture have an autonomous wobble-correction surface with intelligent escalation, or only dashboards? Where does the duty of care live? Who steps away when sleep scores and conceptualization drift compound?
Sovereignty reading. Where does the architecture lock the enterprise into a vendor's continuity? What is the exit cost? How many exit vectors does the architecture preserve?
Safety reading. What is the failure-mode footprint? What gets destroyed if this architecture wobbles at speed? Who is the human whose start position survives the destruction?

The output is structured, quantifiable, and footprint-traced. The assessment is observable in real time during execution if the submitter and author elect public live-streaming.

The intake gate

Submission is not self-serve. Every submission routes through WhatsApp to the appropriate GitHub author before any repository update or external response. This is the first gate and it is not optional.

The flow:

Enterprise user submits an AI-related solution architecture through the public surface (the hyperloop site cover page menu — entry: "Submit an architecture for EVE Glyph reference assessment").
The submission opens a WhatsApp click-to-chat to the lead operator's intake number, with a structured pre-filled message naming the submission's domain, the submitter's institution, and the high-level architecture context.
The lead operator receives the routing on WhatsApp. The lead operator is the network's first human-in-the-loop and reviews the submission for routing.
The lead operator routes the submission to the appropriate GitHub author — the operator whose authored work in the lattice / education / marketplace / hyperloop is most relevant to the submission's domain. Examples: regulated utilities → the operator who authored the EUDG / NB Power lineage; SAP vendor lock-in → the same operator (current state of the network has this concentrated; future state distributes it); iconography proposal → the marketplace author when designated; biological integration → the integration-layer author when designated.
The appropriate GitHub author is the human-in-the-loop for that specific submission. They review the submission, decide whether to engage, and either initiate the assessment or defer.
Only after the author has accepted the routing does the assessment proceed.
Only after the assessment has been performed by or with the author does any repository update happen and any external response return to the submitter.

Until the routing layer is automated, the lead operator performs the routing manually on WhatsApp. This is acceptable because routing is itself an act of judgment that benefits from a human-in-the-loop in the early phase of the service. Automation comes when routing patterns are stable and the network has multiple authors in active operation.

Why routing matters

A network with one author can answer everything. A network with one author also fails when the author wobbles. The routing layer is what makes the network sustainable — it places each submission in front of the operator most able to assess it, and it prevents the lead operator from becoming the choke point on every external engagement.

The routing is also what makes the assessment service trustworthy. An enterprise submitter receives an assessment from the operator whose authored work is the relevant precedent. The assessment carries the weight of that operator's prior work. It is not an automated grader; it is a human assessment grounded in the methodology and signed by the author who performed it.

This is also why the routing happens before the repository update. Repository updates carry authorship; the network refuses to update repositories on submissions the appropriate author has not yet accepted. Authorship integrity flows through the routing.

Live streams and public-domain event monitoring

When an assessment proceeds, it can be live-streamed (with submitter and author consent). The live stream shows the methodology operating on the submission in real time: the footprints emitted as the assessment runs, the wobble detections, the lock-in flags, the start-position checks. The stream is the open-governance posture; the methodology refuses to operate as a black box.

Live streams are correlated with public-domain event monitoring. The assessment is not isolated from the live state of the world the architecture has to operate in. Vendor incidents, AI safety failures, regulated-industry compliance events, market signals — the same kind of signals the hyperloop meter and monitor pages already track — are part of the assessment's input. An architecture being assessed today is read against what is happening in the world today.

The two together mean an assessment is reproducible (the live stream is the record), grounded (public-domain events are the context), and operator-signed (the routed author performed it). That is the reference-model standard.

Output

The submitter receives:

A quantified reading per methodology dimension (fitness, wobble, lock-in, start-position, monitor maturity, sovereignty, safety).
The full footprint trace from the assessment itself — every wobble detection, every lock-in flag, every re-orientation, in time order.
A named author attribution — which GitHub author performed the assessment and what authored work in the network the assessment draws on.
Optional public archival, with submitter consent, so the assessment becomes part of the reference model's accumulating public corpus of worked examples.

The submitter does not receive a verdict. The submitter receives a reading. What the enterprise does with the reading is the enterprise's decision and the reference model takes no position on that.

What this directory does not yet contain

The submission form / structured intake template.
The routing rules engine (operator-matching logic).
The footprint trace format specification for assessments.
The live-stream surface design.
The public-domain event correlation layer.
The public archive structure for consented assessments.

These are the work the service requires. This README is the principle and the architecture; the implementation comes after.

Provenance

Service principle named by the lead operator on 2026-05-16: "any enterprise user should be able to subject AI-related solution architectures and have it automatically assessed based on the EVE Glyph protocols standards which are subject to live streams and public domain event monitoring."

Routing requirement named immediately after, same session: "submissions will require a routing to the appropriate GitHub author via WhatsApp prior to repository update or response to external architecture assessment against the EVE Glyph reference design."

Both principles are extended vectoring instances per Pattern 6 of game/design/observed-operator-patterns.md. Neither produces a new lattice methodology; both belong here as worked teaching material on how the protocol vectors outward to new substrates while preserving its own intake integrity.

© 2026 Dany Theriault. EVE “digital stem cell” glyph and glyph-based design principles — all rights reserved. Stewardship of rights of use and assignment for large public and institutional usage rests with the Pacific Utilities Design Council. Published as a time-stamped record of authorship and intent.
pour le bien-être du peuple