Intake + eligibility
Submission tracks, published limits, required fields, file rules, deadlines, fees where approved, and clear refusal states.
What we build
Four operational problems behind literary and cultural work.
TLS starts with the work people are already trying to carry. The examples below describe what a bounded project may include; they are not fixed packages or promises that every component is currently available.
01 / Move submissions through review
Move work from intake to a documented decision.
A submissions system should make the rules visible, refuse ineligible material before it consumes staff time, separate identity when blind review is required, and preserve a usable record of each decision.
Review + responsibility
Reader assignments, identity controls, scoring or recommendation rules, conflicts, escalation, and a named human decision owner.
Decisions + records
Status changes, withdrawals, correspondence, decision notes, exports, and evidence that the same file did not remain in contradictory queues.
02 / Connect readers, members, and events
Make participation understandable before, during, and after the gathering.
The system may connect a public program page to registration, capacity, access information, schedules, participant communication, resources, attendance records, and a clear operator handoff.
Reader + member paths
Interest, membership or subscription status, preferences, communications, renewals where applicable, and consent-aware records.
Event operations
Program details, registration, capacity, access notes, reminders, check-in, live-room responsibilities, and follow-up.
Resource delivery
Clearly labeled collections, permissions, release timing, accessible formats, expiration or retention rules, and exports.
Talty Literary is an owned program in development, not a client case study or evidence of current registration operations.
03 / Organize rights, records, and archives
Keep the source, the claim, and the next human action connected.
Rights and records work becomes dangerous when a broad answer is inferred from a narrow document. A responsible system keeps dimensions separate, links recommendations to sources, exposes uncertainty, and leaves legal decisions with qualified people.
Rights + license records
Right type, language, territory, format, exclusivity, term, authority source, conflicts, status, and approval history.
Document intake + routing
Bounded extraction, source links, queue rules, exception states, and review before a fact becomes an operational instruction.
Archives + retrieval
Naming, metadata, provenance, permissions, retention decisions, search, export, deletion procedure, and a recoverable record of change.
Inspect the fictional Agency Rights Desk and Kettle Brook Records Desk.
04 / Improve websites and accessibility
Make the public path clear, testable, and possible to operate.
A website is part of the operating system. Its navigation, content, forms, policies, ownership, updates, and failure paths should be documented alongside the code or configuration that renders it.
Public-site structure
Information architecture, page systems, content migration, responsive behavior, forms, redirects, ownership, and launch preparation.
Accessibility evidence
Automated accessibility baselines, keyboard and responsive checks, prioritized repair work, known limits, and records that support—not replace—manual review.
Handoff + continuity
Account and dependency maps, operating instructions, source and export paths, backups, rollback steps, and separately scoped continuing work.
An automated result is not a certification, a guarantee of WCAG conformance, or legal advice.
Some work requires a different responsibility boundary.
Regulated or highly sensitive data, formal procurement, critical uptime, legal interpretation, and security-sensitive infrastructure require client-approved systems and appropriate specialist or counsel review. TLS does not turn a broad capability into an unsupported compliance, deadline, security, or availability guarantee.