White Lion of Judah before a golden kingdom

ENOCH WORLD · CHRIST CALLING 2027

SydTek Trade School Progress | TCN Express & $MOUNT

The Lion of Judah · ENOCH LIVE · A soundtrack for every world

Explore the calling →

SydTek Trade School Progress | TCN Express & $MOUNT

SydTek · TCN Express · $MOUNT

Build the school.
Show the evidence.

A public progress tracker for SydTek Trade School, the TCN Express learning connection and the proposed $MOUNT project context. Follow the source, the work still needed and the decisions that require external confirmation.

Current stage: program design and evidence preparation. Accreditation is an intended future milestone.

Reviewed October 27, 2026 · Fixed source snapshot EW-TRADE-20261027 · No live GitHub synchronization

Read the status accurately

Preparation is visible. Decisions need proof.

This review separates repository documents, example checks, project receipts and external decisions. A published policy shows preparation; adoption, delivery and approval require their own evidence. “Not verified” means the reviewed sources did not establish the claim.

The founding trade-school repository currently contains a README and license. The existing trade-school page separately describes an authored prototype with five paths, twenty missions and five mentors. That description does not establish a published Roblox experience or an independently tested Studio build. This tracker preserves that distinction instead of treating one repository as the full history of the project.

Preparation documented
7
Example validation passed
1
Checks need attention
1
Source access blocked
1
Project record / receipt
2
Not verified
5
Proposed integration
1

18 milestones across four workstreams. These counts describe evidence states, not a percentage of accreditation completed. Proposed owner roles are suggested responsibilities, not verified appointments.

Accreditation status: accreditor selection, eligibility, a formal application, candidacy and a decision have not been verified in the public sources reviewed. Adult trade-school requirements must be assessed separately from the campus repository’s K–12 templates.

Public evidence · read only

Milestones with a source and a next step.

Open a milestone to see what supports its status, what evidence is still needed and a proposed responsible role. Public statuses cannot be changed with the planner below.

All milestones and source links are available below. Filters, downloads and the local planner become available when the page tools load.

Trade-school purposeTrade school · Preparation documented

Purpose documented

What the evidence supports
The founding repository records why physical trades remain important in an AI economy. Its current tree contains README.md and LICENSE. The separate website also describes an authored prototype; this repository review does not erase that work.
Next evidence needed
Confirm the operating entity, intended location, audience and initial program scope. Reconcile the separate prototype bundle with a versioned source release.
Proposed owner role
Institution lead

Source evidence

Skilled-trades curriculumTrade school · Preparation documented

Program outline

What the evidence supports
The campus repository outlines electrical fundamentals, wiring, safety codes, smart infrastructure, data-center power and automation maintenance. The school-specific directory contains an outline, not a complete set of trade syllabi.
Next evidence needed
Publish trade-specific syllabi, prerequisites, contact hours, lab and equipment plans, supervised activities and competency-to-assessment maps.
Proposed owner role
Academic lead

Source evidence

Governance and policy adoptionTrade school · Preparation documented

Framework and templates

What the evidence supports
Governance responsibilities and a policy-adoption resolution template are documented. A template does not establish that a governing body adopted the policy.
Next evidence needed
Provide named responsible roles, signed adoption records, actual meeting minutes, conflicts disclosures and a review calendar.
Proposed owner role
Governing-body secretary

Source evidence

Qualified instructorsTrade school · Preparation documented

Criteria documented

What the evidence supports
The general faculty policy specifies subject mastery, teaching readiness and required training. It does not establish a verified roster of trade instructors.
Next evidence needed
Document instructor assignments, relevant qualifications and licenses where applicable, and completed onboarding and training records.
Proposed owner role
Academic lead

Source evidence

Practical competency assessmentTrade school · Preparation documented

Assessment policy

What the evidence supports
The outcomes policy describes assignments, projects, exams, rubrics, appeals and quarterly review. Trade-specific demonstrations and assessed learner work were not verified.
Next evidence needed
Approve practical demonstration rubrics, safety-critical pass requirements, assessor responsibilities, moderated samples and appeal handling.
Proposed owner role
Assessment lead

Source evidence

Learner records and credentialsTrade school · Example validation passed

Example validation passed

What the evidence supports
The current commit passed its Validate Registry workflow. The validator checks required fields in example JSON records; the sample transcript is explicitly for a Sample Learner. This is not production learner verification.
Next evidence needed
Implement controlled records, evidence references, authorized issuance, retention, correction and appeal handling. Validate real record behavior with approved test data.
Proposed owner role
Registrar and platform lead

Source evidence

Institutional evidence collectionTrade school · Preparation documented

Templates; evidence pending

What the evidence supports
The evidence matrix maps policies to expected artifacts, owner roles and review cadence. All 18 entries in the repository audit-ready checklist remain unchecked at the reviewed commit.
Next evidence needed
Collect adopted minutes, completed training logs, course shells, assessed work, review actions and redacted operating records. Replace example references with actual evidence.
Proposed owner role
Evidence coordinator

Source evidence

Outcomes and improvementTrade school · Preparation documented

Measurement framework

What the evidence supports
The university improvement plan specifies annual goals and quarterly review. The platform architecture defines learning and capability metrics. Published definitions are not reported learner outcomes.
Next evidence needed
Define cohorts and denominators, record actual completion and mastery results, and publish dated review actions with appropriate privacy controls.
Proposed owner role
Quality lead

Source evidence

Platform verificationTrade school · Checks need attention

Checks need attention

What the evidence supports
At the reviewed commit, Validate Registry succeeded while CI, tests and Security Scan failed. The existing read-only Solana verifier concerns GCB token-balance access; it does not verify a credential or establish $MOUNT functionality.
Next evidence needed
Resolve failing checks, verify correct package paths and tests, and document a deployment with acceptance evidence before claiming a live institutional platform.
Proposed owner role
Platform engineering lead

Source evidence

Operating and program authorizationTrade school · Not verified

Authorization not verified

What the evidence supports
The reviewed public sources did not verify an institution-specific operating or program authorization. The claims policy restricts unsupported state-approval claims.
Next evidence needed
Confirm legal entity, jurisdiction, program type and applicable agency, then record the actual authorization or documented exemption determination.
Proposed owner role
Institution lead

Source evidence

Accreditor selection and eligibilityTrade school · Not verified

Selection not verified

What the evidence supports
The Cognia-style crosswalk says final mappings follow accreditor selection. The ACSI-style crosswalk is a K–12 template. Neither establishes an adult trade-school accreditation route or accepted application.
Next evidence needed
Choose an appropriate route for the actual offering and document eligibility against the authority’s current criteria. Confirm the responsible institution and program scope.
Proposed owner role
Institution lead

Source evidence

Application, candidacy and decisionTrade school · Not verified

External decisions not verified

What the evidence supports
No institution-specific application receipt, accepted candidacy, site-visit outcome or accreditation decision was verified in the reviewed public sources. Accreditation remains an intended future milestone.
Next evidence needed
Link official acknowledgment and any subsequent decision with institution name, program or institutional scope, effective date and conditions.
Proposed owner role
Accreditation liaison

Source evidence

TCN canonical sourceTCN Express · Source access blocked

Source access blocked

What the evidence supports
The recovered tcn-express path returned 404 during review. The cause may be access, relocation or availability; no current TCN commit could be verified.
Next evidence needed
Recover an accessible canonical source, confirm ownership and pin the exact revision before importing implementation claims.
Proposed owner role
TCN engineering lead

Source evidence

TCN workflow architectureTCN Express · Project record / receipt

Documented in project records

What the evidence supports
Project records describe order intake, assignment, pickup, batching, routing, delivery, exception and learning capture. The stage contracts on this page are proposed simulation design, not verified recovered runtime code.
Next evidence needed
Reconcile the documented sequence with accessible source, formal input/output schemas and an approved simulation specification.
Proposed owner role
TCN product and curriculum leads

Source evidence

TCN staged expansion and testsTCN Express · Project record / receipt

Prior receipt; verification pending

What the evidence supports
The October 26 project receipt reports a 17-file staged archive and 5/5 synthetic dispatch tests. The reviewed record did not expose the archive, source or test artifacts, so those results were not independently reproduced.
Next evidence needed
Recover the archive, inspect file hashes and test code, reconcile changes with canonical source and reproduce relevant tests.
Proposed owner role
TCN engineering lead

Source evidence

TCN operational readinessTCN Express · Not verified

Operating evidence pending

What the evidence supports
The project record separates staged development from live dispatch, licenses and leases. No reviewed evidence establishes deployed freight operations or campus/site control.
Next evidence needed
Confirm the actual operator and its applicable authority, qualified personnel, reviewed operating procedures, site permissions and deployment evidence before supervised operational work.
Proposed owner role
TCN operations lead

Source evidence

$MOUNT identity and specification$MOUNT · Not verified

Source and utility unverified

What the evidence supports
The intended relationship to the trade school is established by the project direction. A canonical-index entry verifies a Mount Gilead book reference; it does not verify a $MOUNT token, contract, chain, deployment or utility.
Next evidence needed
Provide an owner-approved canonical specification and version; define the role and, if applicable, verified chain/contract identity. Complete governance/security review, reproducible tests, user permissions and independent assessment rules before integration review.
Proposed owner role
Project owner

Source evidence

Trade school, TCN and $MOUNT integrationShared integration · Proposed integration

Proposed connection

What the evidence supports
The proposed connection links approved teaching to logistics simulations, assessed evidence and learner records. $MOUNT remains a proposed project context until its identity and role are specified. The new website tools are separate from the unverified canonical TCN runtime.
Next evidence needed
Approve competency mappings, versioned evidence contracts, data ownership, user permissions and governance/security review. Reproduce interface tests and preserve assessment independence. Public external statuses require their own official evidence.
Proposed owner role
Cross-project product lead

Source evidence

Proposed learning connection

Real skills need assessed evidence.

The intended connection starts with an approved learning outcome. A simulation produces an artifact, a qualified assessor reviews it and an authorized records process decides what may be recorded. Moving between projects does not automatically confer a credential.

01 · Define

SydTek program

Approved competencies, learning activities and practical assessment criteria.

02 · Practice

TCN simulation

Synthetic logistics work with stated constraints and reviewable events.

03 · Assess

Learning evidence

Versioned artifact, rubric, assessor decision and correction history.

04 · Record

Learner record

Authorized, protected recording linked to supporting evidence.

$MOUNT · proposed project context

The intended school relationship is recorded. Its canonical identity, software role and utility still need a specification. No token balance, financial entitlement or property right is inferred from this diagram.

This map is a proposed integration design. Public repository status, the existing trade-school prototype and new tools on this website remain separate evidence categories.

TCN Express · simulation architecture

Eight stages. An evidence trail at every step.

The project record specifies this sequence: order intake, assignment, pickup, batching, routing, delivery, exception and learning capture. The input, output and evidence contracts below are proposed design for a synthetic exercise. The recovered canonical code path was unavailable at review.

New website practice tools: the readiness planner and on-page simulation support a synthetic learning exercise. They do not verify the recovered TCN code, deploy dispatch operations or change the public snapshot.

Open the synthetic TCN practice simulator

  1. Order intake

    Required input
    Synthetic order ID, origin/destination, quantity, ready time and delivery window.
    Proposed output
    Normalized order with validation results and an intake timestamp.
    Evidence to retain
    Versioned input dataset, validation outcomes and permission/synthetic designation.

  2. Assignment

    Required input
    Validated order, simulated resource availability, capacity and assignment constraints.
    Proposed output
    Proposed resource assignment with a stated reason and review status.
    Evidence to retain
    Assignment rule version, constraint checks and recorded human review.

  3. Pickup

    Required input
    Reviewed assignment, shelf/pick time, readiness status and simulated pickup event.
    Proposed output
    Picked-up status, quantities and timestamp; unresolved readiness issues stay visible.
    Evidence to retain
    Readiness and pickup event log, including discrepancies and corrections.

  4. Batching

    Required input
    Picked-up orders, stack compatibility, capacity and delivery windows.
    Proposed output
    Compatible batch or explicit rejection with a constraint explanation.
    Evidence to retain
    Batch membership, capacity/compatibility checks and rejected combinations.

  5. Routing

    Required input
    Accepted batch, stop locations, travel time and congestion assumptions.
    Proposed output
    Proposed stop sequence, estimated arrival windows and stated ETA confidence.
    Evidence to retain
    Routing assumptions, version, estimated/observed event comparison and review.

  6. Delivery

    Required input
    Reviewed route, expected delivery event and simulated proof-of-delivery fields.
    Proposed output
    Delivered, delayed or unsuccessful outcome with planned and actual timestamps.
    Evidence to retain
    Event history and clearly labeled simulated proof of delivery; no live dispatch claim.

  7. Exception

    Required input
    Readiness, capacity, routing or delivery issue; rule and escalation owner.
    Proposed output
    Reviewed resolution, reassignment or halt with a retained reason.
    Evidence to retain
    Issue code, prior state, reviewer decision, resolution and audit history.

  8. Learning capture

    Required input
    Simulation event history, competency map, rubric, assessor role and evidence permissions.
    Proposed output
    Assessed learning artifact ready for authorized record review; no automatic credential.
    Evidence to retain
    Rubric version, assessor decision, redacted evidence reference, provenance and reproducible checks.

The underlying project record also describes identity, last-mile delivery, AI routing, Gemach AI, driver operations, a pilot dataset, customer experience, GEO, incentives and a canonical entry. Keep driver operations, customer status and AI recommendations distinct. One reproducible synthetic route and its recorded events should be reviewed before considering operational data.

Source: TCN project record (access may be required). The October 26 receipt reports 17 staged files and five passing synthetic tests; the actual archive and those test results were unavailable for independent verification in this review.

TCN Express × SydTek Trade School

Practice a logistics decision.

Move four synthetic orders through a guided, eight-stage learning simulation. Compare readiness, vehicle capacity and load compatibility, then review an exception before capturing the learning record.

New website learning simulation; canonical TCN repository integration pending.

All orders, drivers and times below are invented. This exercise sends no orders, dispatches no vehicles and issues no credential. Participation requires no token.

Read the synthetic inputs and planning rules
TCN-SYN-001 · Four synthetic orders · Minutes measured from the selected starting clock
Order Load group Units Ready after Pick time Delivery leg
SYN-O1 Dry 2 0 min 4 min 12 min
SYN-O2 Dry 1 6 min 3 min 8 min
SYN-O3 Chilled 2 10 min 5 min 15 min
SYN-O4 Dry 2 2 min 4 min 6 min
  • SYN-D1: dry loads only; default capacity 4 units. SYN-D2: dry or chilled loads; default capacity 3 units.
  • Dry and chilled orders cannot share a batch. Every batch must fit its driver's selected capacity. Assignment chooses the eligible driver with the least assigned load, breaking ties by driver ID.
  • Orders are processed in ID order. Each batch is picked at one synthetic depot before departure. Wait until each order is ready, add its pick time, then add each fixed delivery leg. Return to the depot adds 6 minutes between batches.
  • Drivers start together and work independently. There is no shared loading queue, traffic model, geography, optimization claim or promised arrival time. The last arrival determines the simulated elapsed time.
  • Readiness and capacity choices below change only this invented scenario. The late-readiness option changes SYN-O3 from 10 to 25 minutes. A simulated delay adds 10 minutes to SYN-D1 before its first delivery. A missing pickup holds SYN-O3 out of the route.

Per driver: starting clock → readiness waits + pick times → fixed delivery legs → 6-minute return between batches. A delay, if selected, is added once. These are deterministic planning assumptions.

The inputs and stage guide remain available without the interactive tools. When the tools finish loading, you can run and export the synthetic exercise.

The eight-stage guide

  1. 01 Order intake

    Input: four synthetic orders and two drivers. Output: valid unique IDs, non-negative times and an eligible driver for every order.

  2. 02 Assignment

    Input: order groups, units and driver capabilities. Output: a deterministic driver assignment that respects each order's capacity requirement.

  3. 03 Pickup

    Input: ready-after times and pick durations. Output: the readiness rules to apply when scheduling pickup; no real pickup is performed.

  4. 04 Batching

    Input: assignments, compatibility and vehicle capacity. Output: batches with one load group, each within capacity.

  5. 05 Routing

    Input: batches, readiness, pick and travel assumptions. Output: cumulative planned arrival times. Optionally introduce one synthetic exception here.

  6. 06 Delivery

    Input: the synthetic route. Output: provisional simulated arrivals. Unavailable pickups remain held; a learner review is still required.

  7. 07 Exception review

    Input: arrival records and any delay or missing pickup. Output: an explicit learner decision to accept the simulated record or hold it for follow-up.

  8. 08 Learning capture

    Input: the plan, event log and review decision. Output: exportable, unassessed evidence with competency and rubric placeholders. This is not a credential.

Your session · local planning only

Prepare the inputs for a reviewable simulation.

Mark the evidence categories you have prepared. The planner identifies missing inputs at each stage and respects the order of the workflow. Selections are your own report: no documents are uploaded, inspected or certified. They remain in memory for this page visit and do not change public milestones.

Export your planning checklist if you want to keep it. This page keeps no saved account record; export before closing it. Without the interactive tools, use the eight-stage requirements above as a manual checklist.

$MOUNT · define the role

A connection to specify, with evidence to supply.

$MOUNT is intended to connect to the trade-school project. The reviewed sources do not yet establish its canonical software or token specification. A published Mount Gilead book reference is a reference publication; it is not a token deployment or an operating institution.

$MOUNT identity fields in this source snapshot
Field Reviewed status Evidence required
Canonical source Unverified Owner-approved repository or specification with a fixed revision.
Chain Unverified A named network, if a token is actually part of the approved design.
Contract Unverified Exact contract identity, source and deployment evidence, where applicable.
Utility Unverified Explicit approved purpose, eligibility rules and tested interfaces.

Academic progress will need its own assessment and records process. The $MOUNT identity fields are not populated using GCB, $ENOCH or ENOCHBUCKS rules. No reviewed source establishes tuition payments, property ownership, financial returns or accredited credentials through $MOUNT.

Six gates before an integration review

These proposed requirements make the next work concrete while the canonical $MOUNT behavior is being specified. Marking a category present is a personal planning action. It does not establish a contract identity, enable transactions or change the public evidence status.

Proposed $MOUNT integration review gates
Gate Required evidence
Approved, versioned specification Canonical source, accountable owner, intended school relationship, exact version and scope approval.
Identity, role and applicable contract Explicit role and either an approved non-token scope or verified chain, contract and deployment identity where a token is intended.
Governance and security review Decision rights, change control, access model, threat review, incident handling and required independent review.
Reproducible integration tests Inspect test artifacts and expected/actual results for approved interfaces, permissions, failures and reversibility.
User permissions and data rules Document voluntary participation, authorized actions, minimization, retention and an understandable withdrawal or correction path.
Independent educational assessment Competency, assessor decisions and learner records remain independent of balances, ownership, payments or project participation.

Inspect the pinned Mount Gilead reference entry.

An intended future milestone

Choose the route. Build the operating evidence.

Institution and program readiness

Confirm the legal entity, location, program type, instructors, facilities, practical assessments and records process. Operating authorization and any required professional or program permissions need their own evidence.

The campus policy library is a useful starting point. K–12 crosswalks and example university records are not automatically adult trade-school approvals.

External review

Accreditor selection, eligibility, application acknowledgment, accepted candidacy and an accreditation decision are separate milestones. Publish the relevant official record when each can be verified.

A local checklist or a 90-day development plan cannot set an external authority’s decision date.

Official routes to evaluate

These are research links, not selected or affiliated authorities. The appropriate route depends on the institution, jurisdiction and actual educational offering.

These links do not establish SydTek eligibility, an application, a candidacy relationship or approval.

Snapshot provenance

The exact sources behind the status.

The repository links below are pinned to reviewed revisions. Milestone cards link specific files and workflow runs. Project-record links may require access. A source snapshot is updated through a new documented review; it is not a live feed.

TCN source review: the recovered canonical path returned 404. No TCN commit was verified. The project receipt is update 5666550393, dated October 26, 2026, in TWIN-TCN-01.

The campus repository includes inconsistent accreditation and candidate labels. This page follows its educational-claims policy: claims of recognized accreditation, state approval and degree authority require verifiable support.

Explore the trade-school prototypeExplore the Abundance Experiment