RouteLedger for district IT

1. Overview and architecture

A proposed district pilot could compare invoice lines with route assignments, delivery records, and district-approved contract tolerances. Any district data connection, accounts-payable export, or exception workflow would require separate implementation and district review. The verified public demonstration runs only on embedded fictional records.

A potential integration could be file-based, subject to the district's actual export formats, security requirements, and vendor permissions. SFTP, CSV manifests, routing data, telematics records, and ERP mappings are discussion topics, not deployed connectors or established production capabilities.

  ILLUSTRATIVE PROPOSED PILOT FLOW, NOT A DEPLOYED INTEGRATION

  VENDORS                     DISTRICT SYSTEMS
  bus vendor invoices         routing / SIS / GPS / contract rates
        |  CSV + manifest (PGP)      |  CSV + manifest (PGP)
        +-------------+--------------+
                      v
             SFTP INBOUND (/in)      per-source dirs + manifests
                      v
          INGEST + VALIDATION        decrypt, checksum, row-count, schema
                      v
            MATCHING ENGINE          invoice line -> route -> service -> rate
              /            \
 candidate match /           \ discrepancy
            v                  v
   AP EXPORT (/out)        EXCEPTION QUEUE
   approved payable        reason code + SLA clock -> staff
   file -> your ERP/AP           |
            \                    /
             v                  v
         DASHBOARDS / REPORTING / AUDIT LOG

A possible district design would receive approved source files and provide a separately scoped review or export for district staff. No existing ERP connection, accounts-payable integration, production queue, or district data feed is represented.

2. Data exchange model

SFTP and encryption

If a district requires file-based exchange, its pilot would first need an agreed transport, account-isolation model, authentication method, encryption standard, and access restrictions. SFTP, SSH keys, optional PGP payload encryption, and source-IP controls are possible requirements to evaluate. No district or vendor account, SFTP endpoint, encryption workflow, or network allow-list is represented as already provisioned.

/in/          files you push to RouteLedger
/in/archive/  processed files moved here after ingest
/out/         files RouteLedger publishes for you to pull
/out/archive/ retained copies of published files
/reject/      files that failed validation, with a paired .error.txt

Cadence

Any exchange cadence, intake interval, manifest requirement, and incomplete-file handling would be determined with the district during pilot scoping. No active polling, established nightly processing, or production intake schedule is represented.

Monitoring and acknowledgment

File acknowledgments, archive and rejection handling, monitoring, alerting, retention, and incident response are proposed pilot controls that a district would need to define and verify. No live monitored pipeline, guaranteed delivery, or production alerting system is claimed.

File naming and CSV conventions

<source>_<district>_<feed>_<YYYYMMDD>_<HHMMSS>_<seq>.csv.pgp
<source>_<district>_<feed>_<YYYYMMDD>_<HHMMSS>_<seq>.manifest.json

fictional example: samplevendor_sampledistrict_invoice_20260824_020115_001.csv.pgp

The following conventions are illustrative discussion examples. Any district format, transport, and validation rule would require separate agreement and implementation.

• Encoding UTF-8 no BOM. Delimiter comma, RFC 4180 quoting. LF or CRLF.
• Header row required; columns mapped by name, so order is not significant and unknown columns are ignored and logged.
• Dates ISO 8601 YYYY-MM-DD; timestamps carry a UTC offset. Money is decimal, no separators or symbols. Identifiers are opaque strings, so leading zeros are preserved.

Control manifest

A district could require a JSON control manifest, row-count checks, and checksum validation as part of a separately implemented pilot. The following manifest is fictional and does not describe an active district feed.

{
  "schema_version": "1.2",
  "feed": "invoice",
  "source_id": "samplevendor",
  "district_code": "sampledistrict",
  "data_file": "samplevendor_sampledistrict_invoice_20260824_020115_001.csv.pgp",
  "generated_at": "2026-08-24T02:01:15-05:00",
  "row_count": 1487,
  "sha256_plaintext": "9f2c4b...e11a",
  "sha256_ciphertext": "3ab77d...90f4",
  "period_start": "2026-08-01",
  "period_end": "2026-08-15"
}

3. File specifications

The following fictional feed examples illustrate one possible district data-mapping approach. Actual exports, available fields, permissions, join keys, and production implementation would need to be separately verified.

3.1 Vendor invoice file feed=invoice

One row per invoice line. A line is the unit of reconciliation.

invoice_id,invoice_line_id,vendor_id,service_date,route_id,run_id,billing_uom,quantity,rate,line_amount
INV-88231,1,SAMPLE,2026-08-04,RT-114,AM,route_day,1,187.50,187.50
INV-88231,2,SAMPLE,2026-08-04,RT-114,PM,route_day,1,187.50,187.50
INV-88231,3,SAMPLE,2026-08-05,RT-220,AM,route_day,1,214.00,214.00
INV-88231,4,SAMPLE,2026-08-04,RT-999,AM,route_day,1,187.50,187.50

3.2 Route / assignment file feed=route

One row per route-run the district assigned for a service day. The "what was supposed to run" side of the match. Key fields: route_id, run_id, service_date, vendor_id, is_active, expected_uom, and an optional contract_rate that drives rate-over-contract checks.

3.3 Service / GPS delivery file feed=service

An illustrative service-record format could include run_status (completed / partial / no_service) and gps_coverage. The availability and suitability of actual telematics records would require district and vendor verification.

route_id,run_id,service_date,vehicle_id,actual_start,actual_end,run_status,gps_coverage
RT-114,AM,2026-08-04,BUS-2210,2026-08-04T06:41:00-05:00,2026-08-04T08:02:00-05:00,completed,0.98
RT-220,AM,2026-08-05,BUS-2247,2026-08-05T06:12:00-05:00,2026-08-05T08:04:00-05:00,completed,0.61
RT-999,AM,2026-08-04,,,,no_service,0.00

3.4 Vendor master file feed=vendormaster

A proposed district-controlled reference file could map vendor_id to erp_vendor_no, remit_to_code, and approved aliases. No existing vendor-master feed, accounts-payable export, or ERP mapping is represented.

4. Matching and reconciliation

Join order

• Vendor resolution. Resolve invoice.vendor_id against Vendor master (directly or via alias). Unresolved or inactive short-circuits to exception.
• Assignment join on route_id + run_id + service_date. If the invoice omits run_id, join on route + date and distribute quantity by expected_uom.
• Service join to the GPS feed for the delivery evidence: run status, actual times, coverage.
• Rate resolution: assignment contract_rate first, then the configured vendor/service-type rate table.
• Scoring against tolerances, then classify.

Illustrative tolerance examples for district review

Exception taxonomy

The verified public demonstration applies deterministic matching rules to fictional embedded records and shows staff-reviewed sample credit actions. Any production classification, persistent event logging, accounts-payable export, or ERP mapping would require separate district approval, implementation, and verification.

Potential AI requirements and hard control boundaries

Any automation beyond the existing deterministic sample matching would require separate implementation, district approval, and security review. The existing sample demonstration is deterministic and does not establish a production AI capability. District staff retain control over every payment and credit.

5. Security and data integrity

The controls below are proposed district-review requirements. They are not established production controls, completed implementations, third-party audits, or security certifications.

Data minimization

A proposed pilot should minimize data to approved route, service, vendor, and contract records. Student PII should not be supplied unless the district explicitly approves a verified need and adequate controls. Any data mapping, retention, exclusion, or storage behavior would require separate district review and implementation.

Encryption and access

• In transit: the district would determine the approved transfer method, encryption standard, authentication, and any payload-encryption requirement.
• At rest: storage encryption, backup handling, key management, retention, and processing boundaries would require documented implementation and district verification.
• Access control: any role model, tenant isolation, SSO, MFA, or identity-provider integration would be separately scoped and reviewed before district data is accepted.
• Audit trail: any persistent, append-only, tamper-evident, or hash-chained event log is a proposed requirement, not an existing verified production capability.

Student-data privacy

Any district privacy agreement, data-processing terms, permitted uses, state-law addenda, and implementation controls would need to be approved before real district information is received. No executed district agreement, completed privacy audit, or certification is represented.

6. Implementation and onboarding

Any district-specific implementation timeline must be scoped after reviewing the district's actual systems, permissions, security requirements, staffing, and approved pilot scope. No delivery date, established onboarding duration, or production go-live is promised.

• Discovery and field mapping. Identify actual district exports, available records, proposed matching rules, approval owners, and privacy requirements.
• Security and transfer design. Agree on any permitted file exchange, authentication, encryption, access restrictions, and validation evidence.
• Approved sample-file review. Examine only district-authorized records after data-handling requirements and permissions are confirmed.
• Implementation and validation. Separately build and verify any approved mapping, reconciliation, logging, review, or export capability.
• District-controlled pilot decision. Begin production handling only after the district approves the implemented controls, workflow, and purchasing requirements.
• Staff handoff. Define training, review responsibilities, exception handling, and support arrangements within the agreed pilot scope.

7. IT FAQ

Do you need write access to our ERP/AP system?

No existing ERP connector or accounts-payable export is represented. If a district approves a file-based workflow, any export, access boundary, and import process would be separately designed, implemented, and verified under district control.

Where is our data hosted?

No district production-hosting arrangement is currently represented. The hosting provider, region, isolation model, subprocessors, storage controls, and agreement terms would need district approval before any production deployment.

How is PII protected?

A pilot should begin with data minimization and district approval of every requested field. Any encryption, role controls, SSO, MFA, retention, or audit logging would require separate implementation and verification before real records are processed.

What if our file format differs from your examples?

Your district's actual exports, column names, formats, permissions, and compatibility would be reviewed during scoping. No existing custom mapping or guaranteed compatibility with any district or vendor system is claimed.

Can we run on-prem or single-tenant?

Any single-tenant, district-hosted, or region-specific deployment would require separate feasibility, security, infrastructure, and pricing review. No such deployment option is represented as already implemented.

How are credentials rotated?

Any credential issuance, key rotation, identity-provider integration, user removal, and access review would be defined with district security staff and verified as part of an approved implementation.

What happens to our data at contract end?

Data ownership, export formats, retention, disposal methods, confirmation evidence, and contract-end responsibilities would be documented and approved before a district pilot accepts any real records.