TUASESOR Product Vision
TUASESOR turns fragmented operations into a structured, traceable, progressively automatable back-office.
This document defines the durable product intent of TUASESOR: why the product exists, who it serves, what outcomes it aims to enable, and the principles that should guide its evolution.
VISION.md is not a description of current implementation, a roadmap, or an architectural specification. Current behavior must be verified against the application, database, and canonical technical documentation. Future directions described here express product intent and do not by themselves create implementation commitments.
For current implementation and technical boundaries, use README.md, ARCHITECTURE.md, REPOSITORY.md, DATABASE.md, and ECOSYSTEM.md. Those sources remain authoritative for their respective concerns.
1. Purpose
Organizations often operate through information and processes distributed across spreadsheets, email, shared folders, documents, specialized systems, and informal communication. Administrative and financial work then depends on repeated data entry, manual coordination, specialist knowledge, and the ability of individuals to reconstruct what happened across disconnected sources.
TUASESOR exists to reduce that fragmentation.
Its purpose is to transform operational information, documents, evidence, responsibilities, and financial activity into workflows that are easier to understand, execute, review, and trace.
At its core, TUASESOR is concerned with the back-office of an organization: the administrative, financial, accounting, evidence-management, compliance, and reporting work required to turn day-to-day activity into controlled and usable organizational information.
The product should progressively reduce manual work and unnecessary context switching without making important operational behavior opaque. Users should be able to understand what happened, what requires attention, who is responsible, and what should happen next.
2. Users and Problems
TUASESOR is intended for organizations and the professionals who support them.
Its strongest initial fit is expected among small and medium-sized organizations that need reliable administrative and financial operations without maintaining large internal administrative structures. This includes foundations and other nonprofit organizations, small and medium-sized businesses, professional teams, and advisors who work across one or more organizations.
The product is not structurally limited to a specific legal form or industry. What matters is the underlying operational problem.
Typical users work in environments where:
- information is distributed across spreadsheets, email, folders, documents, and independent systems;
- evidence and financial activity must be associated with projects, responsibilities, periods, or organizational purposes;
- the same information is entered or reconciled manually more than once;
- responsibilities, pending actions, deadlines, and approvals are difficult to follow;
- accounting or compliance work is disconnected from the operational evidence that produced it;
- specialists spend time reconstructing information instead of reviewing, validating, and advising;
- historical traceability depends excessively on individual knowledge or manual records;
- organizations need greater confidence that information is complete, authorized, and reviewable.
TUASESOR should adapt to real business workflows rather than force organizations to reproduce the internal structure of the software.
3. Product Thesis
TUASESOR is an operational platform for organizations and the professionals who support them, specialized in administration, finance, and accounting.
It converts fragmented information, documents, evidence, and processes into structured and traceable workflows, even when the underlying activity originates outside TUASESOR.
TUASESOR does not aim to replace every system an organization uses. It should progressively connect with existing operational tools and become the layer that organizes and operates the administrative, financial, and accounting back-office where it can provide meaningful value.
This means TUASESOR may work with processes that originate directly inside the product as well as evidence and operational facts produced by external systems.
Over time, that back-office can combine three complementary forms of value:
- Software that structures information, enforces workflow rules, reduces repetitive work, and preserves traceability.
- Professional services in which accountants, advisors, reviewers, or other specialists validate, interpret, correct, audit, and support decisions.
- Contextual intelligence supplied progressively through CORTEXA, helping users understand information, identify what requires attention, prepare work, and eventually execute authorized actions under appropriate controls.
Automation should increase the leverage of people and professionals without hiding relevant decisions or transferring product responsibility to an opaque system.
4. Operating Model
TUASESOR organizes work around the organization as an operational context.
A workspace provides the boundary in which people, responsibilities, documents, evidence, financial activity, processes, states, and dates acquire business meaning. These concepts should not exist merely as independent records; they should help users understand and execute complete workflows.
The operating model should make it possible to answer practical questions such as:
- what happened;
- what information or evidence supports it;
- which organization, project, period, or purpose it belongs to;
- who is responsible for the next action;
- what state the process is currently in;
- what remains incomplete or requires review;
- which decisions or approvals occurred;
- how the process reached its current state.
Traceability is therefore a product capability rather than a reporting feature added after the fact.
TUASESOR should preserve enough context throughout a workflow that users and professionals can reconstruct relevant events without depending on disconnected spreadsheets, email threads, folder structures, or individual memory.
The product may provide different views over this operational context depending on the user's role. A person working inside one organization may primarily operate within that workspace, while a professional supporting several organizations may require cross-workspace visibility. These views should reuse the same underlying business context rather than create parallel representations of the organization.
5. Administrative and Accounting Backbone
TUASESOR's financial and accounting direction begins with operational evidence and the business events that evidence represents.
The intended conceptual flow is:
operational activity -> evidence and movements -> accounting entries -> accounting records -> financial reporting -> compliance and decision support
Expense reports (Rendiciones) are an important initial workflow and can provide one structured source of financial movements, but they must not define the accounting model of the entire product.
The accounting backbone should remain capable of receiving movements from multiple authorized sources without requiring each source to understand the internal structure of the others.
Conceptually:
Rendiciones --------+
External evidence --+
Financial systems --+
Other sources ------+
v
accounting backbone
|
v
journal entries
|
v
general ledger
|
v
balances / financial reports
The accounting layer should operate on accounting records and validated business facts, not directly on the internal implementation details of a single upstream workflow.
This separation allows TUASESOR to evolve from a strong first administrative workflow into a broader financial and accounting back-office without redesigning the core each time a new source of information becomes relevant.
Tax, statutory reporting, electronic tax documents, government integrations, and other compliance processes are natural areas of possible evolution where customer value is validated. They are not implied to be implemented or committed merely because they belong naturally to the back-office domain.
6. Connected Back-Office
TUASESOR does not require all operational activity to originate inside the product.
Organizations already use specialized systems for commerce, banking, documents, communication, payroll, customer management, government services, and many other operational domains. Rebuilding those systems inside TUASESOR would increase complexity without necessarily increasing customer value.
The preferred product direction is integration before unnecessary replication.
When there is a meaningful business use case, TUASESOR should be able to receive or access authorized information from external systems, normalize the relevant business facts, and incorporate them into its administrative, financial, and accounting workflows.
Conceptually:
operational systems
|
v
documents / evidence / business events
|
v
TUASESOR
|
v
structured back-office workflows
|
+--> administration
+--> finance
+--> accounting
+--> reporting
+--> compliance
This makes TUASESOR useful even when the organization's primary operation happens elsewhere.
A business may conduct commerce through an external platform. An organization may store evidence with an external document provider. Financial information may originate from banking or government systems. Those systems remain authoritative for the activities they own, while TUASESOR provides the business context required to transform relevant information into controlled back-office workflows.
Specific providers and integrations should be selected according to validated user and business needs. Examples of external systems illustrate this product direction; they do not constitute implementation commitments.
This connected model also allows TUASESOR to serve organizations that do not want to replace their existing operational tools but need a stronger administrative and accounting layer around them.
7. Software and Professional Services
TUASESOR is designed to create value through software while remaining compatible with professional services where organizations need specialized judgment, review, or operational support.
Software should structure information, enforce workflow rules, identify incomplete or inconsistent work, preserve evidence, reduce repetitive tasks, and make the state of a process understandable.
Professional work should concentrate increasingly on the activities where expertise matters most: reviewing, validating, correcting, interpreting, auditing, advising, and making decisions that require professional judgment.
The intended relationship is therefore not software versus professionals. TUASESOR should increase the leverage of professionals by reducing the administrative effort required to reach reliable information.
Conceptually:
raw information / evidence
|
v
TUASESOR
|
+--> structure
+--> validate
+--> automate
+--> trace
|
v
professional review and judgment
|
v
validated outcome / advice / decision
This model allows TUASESOR to support different service arrangements over time. Some organizations may primarily use the software themselves, while others may operate with accountants, advisors, reviewers, or managed support around the same underlying workflows.
Those service models should evolve from validated customer needs rather than from a requirement to package every workflow as a professional service.
TUASESOR should not present automation as a substitute for professional responsibility where specialized review, legal accountability, accounting judgment, or organizational approval remains relevant.
8. Intelligence and Controlled Agency
Intelligence in TUASESOR should be embedded progressively into real business workflows rather than introduced as an isolated chatbot or a parallel experience disconnected from the product.
The intended progression is:
ambient intelligence
|
v
contextual assistance
|
v
Command Center
|
v
controlled agents
Ambient intelligence should help users notice relevant conditions directly where work happens: missing evidence, unusual situations, incomplete processes, inconsistencies, deadlines, or other signals that deserve attention.
Contextual assistance should allow users to ask for explanations, summaries, reviews, preparation, or guidance from the context of the workflow they are already operating.
Command Center should provide a transversal interface for finding information and initiating authorized actions across TUASESOR. It can begin with deterministic search and actions and progressively evolve toward a contextual intent interface without requiring users to know where every piece of information or capability is located.
Controlled agents represent a further stage in which authorized workflows may be executed with increasing autonomy when the use case, permissions, data boundaries, traceability, and required human controls are sufficiently defined.
Agentic behavior should not mean unrestricted access or opaque autonomy. Higher-impact actions should require controls proportional to their consequences, including explicit authorization, least privilege, traceability, and human review or approval where appropriate.
CORTEXA is the reusable intelligence platform intended to support this progression as specific capabilities are validated and integrated. TUASESOR remains responsible for the product context in which those capabilities operate: user experience, workspace authorization, business rules, operational state, relevant data boundaries, and the decisions that require human accountability.
TUASESOR and CORTEXA therefore have complementary but distinct responsibilities. TUASESOR defines what an authorized action means for the vertical product; CORTEXA can provide reusable capabilities for understanding context, reasoning over authorized information, and executing controlled intelligence workflows.
Advanced agents are a product direction, not an assertion of current implementation or a commitment to broad autonomous behavior.
9. Ecosystem and Product Boundaries
TUASESOR is a vertical product with its own users, business workflows, product experience, operational context, and data responsibilities.
Its place within the broader Planetta ecosystem should allow TUASESOR to benefit from reusable horizontal capabilities without transferring product-specific responsibilities into shared platforms.
CORTEXA is the most important example of this relationship. TUASESOR can act as a reference vertical for validating and consuming reusable intelligence capabilities while preserving a clear separation between the vertical product and the intelligence platform.
TUASESOR remains responsible for:
- product purpose and customer experience;
- workspace and vertical authorization;
- business workflows and domain rules;
- operational state and user-facing decisions;
- the authoritative context required to interpret actions correctly;
- appropriate handling of sensitive vertical information.
Shared platforms such as CORTEXA should remain reusable and decoupled from TUASESOR-specific business behavior.
The relationship can be summarized as:
TUASESOR defines the business meaning and authorized context; shared capabilities provide reusable infrastructure or intelligence that supports that experience.
This separation also protects TUASESOR from becoming the owner of every reusable capability it consumes and protects shared platforms from accumulating vertical business rules that belong inside TUASESOR.
The product vision describes these strategic boundaries. It does not define legal ownership, licensing terms, commercial agreements, intellectual-property transfers, or other contractual arrangements between TUASESOR, Planetta, CORTEXA, or related parties.
Likewise, the existence of another product or platform in the Planetta ecosystem does not by itself create a TUASESOR integration, dependency, roadmap item, or product requirement. Cross-product relationships should arise from validated business value and explicit boundaries.
10. Evolution, Trust and Non-Goals
TUASESOR should evolve by strengthening complete business workflows rather than by accumulating disconnected features.
Product evolution should distinguish explicitly between three different levels of commitment:
- Current reality: capabilities that exist and can be verified in the product and its canonical technical documentation.
- Product direction: durable outcomes and principles that TUASESOR is intentionally designed to support over time.
- Exploration: opportunities that may become valuable but still require validated user needs, business value, scope, dependencies, and implementation decisions.
A direction described in this document should not be interpreted as an implementation claim, delivery date, contractual commitment, or roadmap item.
Trust as a Product Property
TUASESOR operates in workflows where documents, financial information, organizational responsibilities, professional judgment, and potentially sensitive data can have meaningful consequences.
Trust must therefore be designed into the workflow itself.
The product should progressively preserve evidence of:
- what occurred;
- which information supported it;
- who or what initiated an action;
- which authorization applied;
- which decisions or approvals were required;
- how relevant information changed;
- what remains incomplete, exceptional, or subject to review.
Automation should remain understandable. Authorization should follow least-privilege principles. Access to information should be constrained by the relevant workspace and business context. Higher-impact automated actions should use human review or approval when the consequences justify it.
Privacy, authorization, traceability, and evidence are not implementation details added only for compliance. They are part of the value proposition of a reliable back-office.
Transparency and Nonprofit Organizations
Foundations and other nonprofit organizations represent a particularly strong product fit because their administrative and financial work frequently requires resources, purposes, projects, evidence, approvals, accounting, expense reporting (Rendiciones), and institutional reporting to remain connected.
A useful conceptual chain is:
funding or resource -> origin / purpose / project -> expenditure -> evidence -> accounting -> expense reporting (Rendiciones) -> reporting / transparency
TUASESOR should be capable of strengthening this chain where the organization requires it, helping preserve the relationship between resources received, how they were used, the evidence that supports that use, and the resulting administrative or financial records.
The exact reporting, disclosure, tax, or legal obligations applicable to an organization depend on its context and should not be inferred universally from this product vision.
Product Non-Goals
TUASESOR should deliberately avoid several forms of unnecessary complexity.
It is not intended to become:
- a generic ERP that attempts to reproduce every operational system used by an organization;
- a replacement for specialized commerce, banking, payroll, document-management, CRM, POS, or government platforms when integration provides better value;
- a collection of technical modules exposed directly to users without a coherent business workflow;
- an autonomous system with unrestricted access to organizational information or high-impact actions;
- a substitute for professional accountability or organizational decision-making where human judgment remains relevant;
- a product whose future explorations are presented as capabilities that already exist.
The durable objective is simpler:
TUASESOR turns fragmented operations into a structured, traceable, progressively automatable back-office.